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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



£75/ 



3GPP TS 24.302 version 1 1 .4.0 Release 1 1 8 ETSI TS 1 24 302 V1 1 .4.0 (201 2-1 0) 



Scope 



The present document specifies the discovery and network selection procedures for access to 3GPP Evolved Packet 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

Access Network Discovery and Selection Function: In this specification. Access Network Discovery and Selection 
Function (ANDSF) is a network element specified in 3GPP TS 23.402 [6]. Unless otherwise specified, the term ANDSF 
is used to refer to both Home and Visited ANDSF. 

Emergency session: In this specification, an emergency session is an emergency PDN connection estabhshed in E- 
UTRAN and handed over to a S2a based cdma2000® HRPD access network. 

Home ANDSF: In this specification, the Home ANDSF (H-ANDSF) is an ANDSF element located in the home PLMN 
of a UE. 

Set of Access network discovery information: In this specification, a set of Access network discovery information is 
the access network discovery information from a single ANDSF. 
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Set of Inter-system mobility policy: In this specification, a set of Inter-system mobility policy is the inter-system 
policy information received from a single ANDSF. 

Visited ANDSF: In this specification, the Visited ANDSF (V-ANDSF) is an ANDSF element located in the visited 
PLMN of a UE. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.122 [4] apply: 

EHPLMN 
Home PLMN 
RPLMN 
Visited PLMN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.402 [6] apply: 

IFOM capable UE 

Local Operating Environment Information 

MAPCON capable UE 

S2a 
S2b 
S2c 
Non-seamless WLAN offload capable UE 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 29.273 [17] apply: 

STa 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.301 [10] apply: 

Evolved packet core network 
Evolved packet system 

For the purposes of the present document, the following terms and definitions given in 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25] apply: 

Network Access Provider 
Network Service Provider 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 33.402 [15] apply: 

External AAA server 



3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

AAA Authentication, Authorization and Accounting 

ACL Access Control List 

AKA Authentication and Key Agreement 

ANDSF Access Network Discovery and Selection Function 

ANDSF-SN Access Network Discovery and Selection Function Server Name 

ANID Access Network Identity 

APN Access Point Name 

DHCP Dynamic Host Configuration Protocol 

DM Device Management 

DNS Domain Name System 

DSMIPv6 Dual-Stack MIPv6 

eAN/PCF Evolved Access Network Packet Control Function 

EAP Extensible Authentication Protocol 

EPC Evolved Packet Core 

ePDG Evolved Packet Data Gateway 
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EPS Evolved Packet System 

ESP Encapsulating Security Payload 

FQDN Fully Qualified Domain Name 

GAA Generic Authentication Architecture 

GBA Generic Bootstrapping Architecture 

HA Home Agent 

H-ANDSF Home-ANDSF 

HRPD High Rate Packet Data 

HSGW HRPD Serving Gateway 

IEEE Institute of Electrical and Electronics Engineers 

IFOM IP Flow Mobility 

IKEv2 Internet Key Exchange version 2 

IPMS IP Mobility Mode Selection 

ISRP Inter-System Routing Policies 

I-WLAN Interworking - WLAN 

MAPCON Multi Access PDN Connectivity 

MO Management Object 

NAI Network Access Identifier 

NAP Network Access Provider 

NBM Network based mobility management 

NSP Network Service Provider 

OMA Open Mobile Alliance 

PCO Protocol Configuration Options 

P-GW PDN Gateway 

PDU Protocol Data Unit 

S-GW Serving Gateway 

SPI Security Parameters Index 

UE User Equipment 

UICC Universal Integrated Circuit Card 

V-ANDSF Visited-ANDSF 

W-APN WLAN APN 

WiMAX Worldwide Interoperability for Microwave Access 

WLAN Wireless Local Area Network 

WMF WiMAX Forum 



General 



4.1 



Trusted and untrusted accesses 



The HPLMN operator of the EPC selects whether a connected non-3GPP IP access network is a trusted or untrusted IP 
access network. 

For a trusted non-3GPP IP access network the communication between the UE and the EPC is secure. For an untrusted 
non-3GPP IP access network the communication between the UE and the EPC is not trusted to be secure. 

For a trusted non-3GPP IP access network, all communication between the access network and the EPC is transferred 
over pre-established secure links.For an untrusted non-3GPP IP access network, to secure communication between the 
UE and the EPC: 

A single IPSec tunnel needs to be established to the ePDG for all PDN connections when S2c interface is used; 
or 

An IPSec tunnel needs to be established with the same ePDG for each PDN connection when S2b interface is 
used. 
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4.2 cdma2000® HRPD Access System 

The cdma2000® HRPD system is a wireless mobile system developed under the auspices of 3GPP2. The cdma2000® 
HRPD system and its access network subsystem is compliant with 3GPP2 X.S0057 [20] and 3GPP2 C.S0087 [21], 
which define the core network and air interface aspects, respectively. 



4.3 WiMAX Access System 



The WiMAX system is a wireless mobile broadband system developed under the auspices of the WMF and the IEEE. 
The WiMAX system and its access network subsystem are compliant with WiMAX Forum Network Architecture 
Release 1.0 version 1.2 - Stage 2 [24]. The protocol architecture and signalling of the WiMAX system is specified in 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25] which supports the air interface defined in 
WiMAX Forum Mobile System Profile Release 1 .0 Approved Specification Revision 1 .4.0 [26] specifying selected 
profiles of IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Corl-2005 [27] that are to be supported. The WiMAX 
access system correspond to the WiMAX Access Service Network (ASN) and to relevant interfaces, as defined in 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25]. 

4.4 Identities 

4.4.1 User identities 

The user identification shall be either the root NAI, or the decorated NAJ as defined in 3GPP TS 23.003 [3], when the 
UE accesses the EPC via non-3GPP access networks, and gets authentication, authorization and accounting services 
from the EPC. For handover of an emergency session from E-UTRAN to a S2a based cdma2000® HRPD access 
network, if IMSI is not available (i.e. a UE without USIM) or IMSI is unauthenticated, the IMEI shall be used for the 
identification, as part of the emergency NAI as defined in 3GPP TS 23.003 [3]. 

User identification in non-3GPP accesses may require additional identities that are out of the scope of 3GPP. 

IETF RFC 4187 [33] and 3GPP TS 23.003 [3] provide definitions for UE and user identities although they use slighdy 
different terms. Similar terms are also used in 3GPP TS 33.402 [15]. The following list provides term equivalencies and 
describes the relation between various user identities. 

- The Root-NAI as specified in 3GPP TS 23.003 [3] is to be used as the permanent identity as specified in 
3GPPTS 33.402 [15]. 

The Fast-Reauthentication NAI as specified in 3GPP TS 23.003 [3] is to be used as the Fast-Reauthentication 
Identity or the re-authentication ID as specified in 3GPP TS 33.402 [15]. 

The Pseudonym Identity as specified in 3GPP TS 23.003 [3] is to be used as the Pseudonym as specified in 
3GPPTS 33.402 [15]. 

4.4.2 Identification of IP Services/PDN connections 

For access to EPC the Access Point Name (APN) is used for identifying IP services/PDN connections. The detailed 
definition of APN as used for access to EPC is specified in 3GPP TS 23.003 [3]. APN is used in the IKEv2 signaling 
during tunnel establishment and tunnel modification. 

4.4.3 FQDN for ePDG Selection 

An ePDG Fully Qualified Domain Name (ePDG FQDN) is constructed by UE and used as input to the DNS mechanism 
for ePDG selection. 

The detailed format of this ePDG FQDN is specified in 3GPP TS 23.003 [3]. 
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4.4.4 Access Network Identity 

For access to EPC through a trusted non-3GPP access network via S2a the UE has to use the Access Network Identity 
(ANID) in the key derivation (see 3GPP TS 33.402 [15]). The handhng of the Access Network Identity is described in 
subclause 6.4.2.4 and the generic format and specific values for the Access Network Identity are defined in 
subclause 8.1.1. 

4.4.5 ANDSF Server Name 

The ANDSF Server Name (ANDSF-SN) is used for ANDSF discovery. The detailed rules are defined in 
subclause 6.8.2.2.1 and the format of the ANDSF-SN is specified in 3GPP TS 23.003 [3]. 



4.4.6 Home Agent address(es) 



If DSMIPv6 is used, the Home Agent IPv6 address (and optionally an IPv4 address) are needed. Within this 
specification, Home Agent address(es) signalling via IKEv2 between the UE and the ePDG is defined in 
subclause 7.4.1. 

4.4.7 Security Parameters Index 

The Security Parameters Index (SPI, see IETF RFC 4301 [30]) identifies uniquely a security association between the 
UE and the ePDG. For the case of NBM using S2b a one to one mapping between SPI and PDN connection applies. 

4.5 Fixed Broadband Access System 

The Fixed Broadband Access system is a type of high-speed Internet access for multi-service broadband packet 
networking. The Fixed Broadband Access system is specified by the Broadband Forum, including addressing 
interoperability, architecture and management. 

For support of Fixed Access Broadband access interworking, the EPC network procedures and the UE procedures are 
specified in 3GPP TS 24.139 [51]. 



5 Network Discovery and Selection 

5.1 Access network discovery and selection procedures 
5.1.1 General 

If PLMN selection specified in 3GPP TS 23.122 [4] and in 3GPP TS 24.234 [9] is applicable (e.g., at switch on, 
recovery from lack of coverage, or user selection of applicable access technology), the PLMN selection to select the 
highest priority PLMN according to these specifications is performed before any access network discovery and 
selection procedures based on ANDSF rules are performed in the selected PLMN. 

In the access network discovery procedure the UE may get from the ANDSF information on available access networks 
in its vicinity. The UE may obtain this information by querying the ANDSF, and may use this information when 
determining the presence of operator preferred access networks. Determination of the presence of access networks 
requires using radio access specific procedures, which are not further described here. 

The UE can first select an access network and then determine the presence of this access network, or first determine the 
presence of several access networks and then select between them. If a higher priority access network has been found 
connected to the same PLMN or a higher priority PLMN, the UE will then attempt to attach via that network. 
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5.1 .2 Access network discovery procedure 

5.1 .2.1 Triggering the discovery of operator preferred access networks with the 
ANDSF 

The UE may initiate communications with the ANDSF for operator preferred access network discovery: 

when conditions set up within the poHcies available in the UE are met; or 

when a user requests for manual selection. 

NOTE 1 : The minimum allowed time interval between two consecutive UE initiated requests towards the ANDSF 
can be set by operator policies. 

NOTE 2: The UE changing of access networks can override the minimum allowed time interval setting. 

5.1 .2.2 Discovering availability of access networks 

The UE may apply the techniques specific to the non-3GPP access technologies to discover available non-3GPP access 
networks. Such techniques will not be further described here. 

In addition, the UE may signal to the ANDSF to obtain information on operator preferred access networks. The 
discovery of the ANDSF by the UE, the connection to the ANDSF by the UE and the signalling between the UE and the 
ANDSF are given in subclause 6.8. 

5.1 .3 Access network selection procedure 

5.1.3.1 General 

The access network selection may be classified as inter-technology or intra-technology. 

The UE can use information received from ANDSF for inter-technology access network selection; other mechanisms 
for inter-technology access network selection are out of scope of this specification. 

5.1 .3.2 Specific intra-technology access network selection 

In this release of the specification the use of the following specific intra-technology access network selection 
procedures is specified. 

5.1 .3.2.1 cdma2000® HRPD access network selection 

The access network selection process for cdma2000® HRPD access networks shall follow 3GPP2 X.S0057 [20]. 

5.1 .3.2.2 WIMAX NAP selection 

The access network selection process for WiMAX which encompasses the NAP discovery and access, shall follow the 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25]. 

5.2 EPC network selection 
5.2.1 General 

The following EPC network selection procedures are defined: 

1) WiMAX specific; 

2) EPC network selection via cdma2000® HRPD access is given in 3GPP TS 23.122 [4] with any exceptions 
detailed in subclause 5.3.4. 
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3) EPC network selection via WLAN access shall follow the procedures defined for PLMN selection given in 
subclause 5.2 of 3GPP TS 24.234 [9] with the exception of the tunnel set up procedure. When the UE is 
connected to EPC through WLAN access, the tunnel is set-up with the ePDG (as described in clause 7 of this 
document) or with the HA (as described in 3GPP TS 24.303 [11]); and 

4) Generic EPC network selection for other access technologies not listed above. 

The UE can utilize information received from ANDSF to which EPCs an access network is connected as described in 
3GPP TS 24.312 [13]. Additionally, any technology specific means can be employed to acquire such information, but 
these are out of scope of this specification. 

NOTE: There are no specific EPC network selection procedures specified for emergency access in this version of 
the specification. 

5.2.2 Generic EPC network selection procedure 

5.2.2.1 Identification of the EPC 

The identification of EPC shall be based on one of the following: 

- PLMN-Id (i.e. pair of MCC+MNC), as specified in 3GPP TS 23.003 [3]; or 

- Home/Visited Network Realm/Domain, as specified in 3GPP TS 23.003 [3]. 

5.2.2.2 Selection at switch-on or recovery from lack of coverage 

5.2.2.2.1 UE selection modes 

Two modes of EPC network selection are defined, manual and automatic. 

At switch-on or following recovery from lack of coverage, the UE shall select the EPC network according to the 
selected operating mode. 

5.2.2.2.2 Manual EPC network selection 

The UE shall present the list of available EPC networks, to which connectivity is provided through the selected non- 
3GPP access network, to the user. If UE"s HPLMN or PLMNs equivalent to it are in this list, they shall be shown in the 
highest ranking order. The ordering of the rest of entries in the list is implementation dependent. If available, the UE 
should display names and/or realms/domains. 

If multiple equivalent HPLMNs are available, then the display order among them is UE implementation specific. 

5.2.2.2.3 Automatic EPC network selection 

The UE may use locally stored data for selecting between EPC networks available for connectivity via the currently 
selected non-3GPP access network. 

The UE shall select a PLMN according to the PLMN selection procedures of the selected non-3GPP access network. 

Additional criteria are out of scope of this specification and remain implementation specific. 

5.2.3 Access technology specific EPC network selection procedures 
5.2.3.1 EPC network selection procedures for WiMAX 

5.2.3.1 .1 Identification of the EPC by the WiMAX access network 

With WiMAX as a non-3GPP access network, the WiMAX NSP is mapped onto the EPC network operator. The NSP 

indication can be provided to the UE in accordance to WiMAX Forum Network Architecture Release 1 .0 

version 1.2 [25]. The WiMAX access network should advertise the NSP identity of the EPC in the MCC, MNC format. 
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5.2.3.1 .2 Selection at switch-on or recovery from lack of coverage 

5.2.3.1 .2.1 UE selection modes 

There are two modes of network selection, namely, manual network selection and automatic network selection. 

At switch-on or following recovery from lack of coverage, the UE shall follow one of the following two procedures 
depending on its operating mode. 

5.2.3.1 .2.2 Manual EPC network selection 

The manual network selection for WiMAX access shall follow the WiMAX Forum Network Architecture Release 1.0 
version 1.2 - Stage 3 [25] with the following exceptions and additions: 

When presenting the list of available networks for user selection, the UE shall provide the network name of the 
related MCC + MNC pair. If that is not possible, the UE shall provide the MCC + MNC pair; and 

If the UE is unable to register to the user selected NSP, further UE action is implementation dependent. 

5.2.3.1 .2.3 Automatic EPC network selection) 

The automatic network selection for WiMAX access shall follow the WiMAX Forum Network Architecture Release 1 .0 
version 1.2 - Stage 3 [25] without any exceptions or additions. 

5.3 Access Network reselection 

5.3.1 General 

The network reselection procedure shall be executed based on the user's request or the operator's policy. Such operator 
policy for supporting network reselection can be provided by the ANDSF or can be pre-provisioned in the UE. 

5.3.2 UE procedures 

The UE may retrieve information from ANDSF, which includes available access network and operator's policy as 
specified in subclause 6.8.2. 

The information which is retrieved from the ANDSF shall not impact the PLMN selection and reselection procedures 
specified in 3GPP TS 23.122 [4] and in 3GPP TS 24.234 [9]. 

The network reselection procedure can be in automatic mode or manual mode dependent on UE configuration settings. 
For WiMAX access, the manual mode reselection shall follow the behaviour described in subclause 5.2.3.1.2.2 and the 
automatic mode reselection shall follow the behaviour described in subclause 5.2.3.1.2.3. 

5.3.3 EPC procedures 

The ANDSF shall send available access network(s) and operator's policy to the UE in response to the UE"s request or 
based on the network triggers as specified in subclause 6.8.2. 

5.3.4 Periodic EPC network reselection attempts 

In automatic mode, when UE is not in its HPLMN or one of its equivalent HPLMNs, the UE shall make a periodic 
attempt to return to its HPLMN or one of its equivalent HPLMNs. For this purpose the timer value given in the 
EFhpplmn as defined in 3GPP TS 31.102 [45] shall be used with the following exceptions:- 

For UE accessing the EPC via cdma2000® HRPD access networks, the UE's search for a more preferred system 
shall abide by the parameters and procedures defined in 3GPP2 C.S0016 [23a]. 

For UE accessing the EPC via WiMAX access networks, the time period between periodic network searches is 
implementation specific. 
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For UE accessing the EPC via any other non-3GPP access networks, unless the UE has availability to EFhpplmn^ 
the time period between periodic network searches is implementation specific but shall not be less than 30 
minutes. 



5.4 Data traffic routing of IP flows 

5.4.1 General 

An IFOM capable UE or a non-seamless WLAN offload capable UE, or a MAPCON capable UE can have several sets 
of information about access technologies or access networks or both to assist in determining the data traffic routing of 
IP flows. These sets of information are: 

the Inter-System Routing policies. For an IFOM capable UE or a non-seamless WLAN offload capable UE, or a 
MAPCON capable UE or any combination of these capabilities, the ISRP can be statically provided within that 
UE. Additionally, the ISRP can be provided by the H-ANDSF or the V-ANDSF or both; 

the Local Operating Environment Information. The Local Operating Environment Information can be optionally 
generated by the UE locally and the contents of Local Operating Environment Information is implementation 
dependant; and 

user preference settings. 

The availability of the above sets of information to the UE is optional. This clause describes the relationship amongst 
these information sets and how they are used in order to route data traffic of IP flows. The Local Operating 
Environment Information does not apply to a MAPCON capable UE in this version of the specification. 

5.4.2 Access technology or access network selection 

When selecting the access technologies or access networks or both to route the data traffic of IP flows, a UE configured 
for IFOM or a UE configured for non-seamless WLAN offload provided with user preferences and having ISRP, or 
Local Operating Environment Information or both may perform the following: 

when selecting the access technology or access network or both for routing data traffic of specific IP flow the 
user preference settings take precedence over ISRP (if present) and Local Operating Environment Information (if 
present). 

When selecting the access technologies or access networks or both to route the data traffic of IP flows, a UE configured 
for IFOM or a UE configured for non-seamless WLAN offload having both ISRP and Local Operating Environment 
Information may perform the following: 

if based on the content of Local Operating Environment the UE configured for IFOM or the UE configured for 
non-seamless WLAN offload decides that an access technology or access network or both do not meet 
implementation specific criteria for routing data traffic of certain IP flows, the UE configured for IFOM or the 
UE configured for non-seamless WLAN offload may exclude that access technology or access network or both 
when deciding on the routing of the data traffic for those IP flows. 

When selecting the access technologies or access networks or both to route the data traffic of IP flows, a UE configured 
for IFOM or a UE configured for non-seamless WLAN offload with Local Operating Environment Information having 
no available ISRP nor user preference settings may perform the following: 

the UE configured for IFOM or the UE configured for non-seamless WLAN offload selects the access 
technology or access network or both for routing data traffic of specific IP flow by evaluating the available 
access technologies or access networks against the Local Operating Environment Information. 

When a UE configured for MAPCON selects the access technologies or access networks or both, to route the data 
traffic of a specific APN, the user preference settings shall take precedence over ISRP (if present). 
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6 UE - EPC Network protocols 

6.1 General 

6.2 Trusted and Untrusted Accesses 

6.2.1 General 

For a UE, the trust relationship of a non-3GPP IP access network is determined by the home PLMN operator. That trust 
relationship is indicated to the UE via the following methods: 

Pre-configured policies in the UE by the home PLMN operator. 

Dynamic indication during 3GPP-based access authentication. 

For a trusted non-3GPP IP access network, the UE shall follow the access methods given in subclause 6.4. For an 
untrusted non-3GPP IP access network, the UE shall follow the access methods given in subclause 6.5. 

If the dynamic trust relationship indication is received during 3GPP-based access authentication, the UE shall rely on 
the dynamic trust relationship indication. Otherwise the UE shall follow the pre-configured policies for a specific non- 
3GPP access network. If no dynamic indicator is received, and no pre-configured policy matches a specific non-3GPP 
access network where the UE attempts to access, the UE shall follow the procedure defined in subclause 6.2.4. 

6.2.2 Pre-configured policies in the UE 

The following types of policies can be pre-configured on the UE by the home PLMN operator: 

Pre-configured trust relationship policies for specific non-3GPP access technologies and/or PLMNs. For 
example, the UE may be configured to use the procedures for trusted access networks as described in 
subclause 6.4 as follows: 

an access network of access technology XI from PLMN Yl is trusted; and/or 

any access network of access technology X2 is trusted; and/or 

any access network from PLMN Y2 is trusted; and/or 

any access network is trusted. 

The format of the pre-configured policies is not specified in this release of this specification. 

6.2.3 Dynamic Indication 

If the UE performs 3GPP-based access authentication, the 3GPP AAA server may send a trust relationship indicator of 
the non-3GPP access network to the UE during the EAP-AKA or EAP-AKA' based access authentication (i.e. EAP- 
AKA, EAP-AKA') as specified in 3GPP TS 33.402 [15]. The indicator is sent using a AT_TRUST_IND attribute, by 
extending the EAP-AKA (and EAP-AKA') protocol as specified in subclause 8.2 of IETF RFC 4187 [33]. This attribute 
is provided in EAP-Request/AKA-Challenge or EAP- Request/AKA'-Challenge message payload respectively. The 
detailed coding of this attribute is described in subclause 8.2.3.1. 

6.2.4 No trust relationship information 

If no dynamic indicator is received, and no pre-configured policies matches a specific non-3GPP access network where 
the UE attempts to access, the UE shall consider it as untrusted network and operate based on subclause 6.5. 
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6.3 IP Mobility Mode Selection 

6.3.1 General 

The IP mobility mechanisms supported between 3GPP and non-3GPP accesses within an operator and its roaming 
partner's network may be based on either: 

a) Static Configuration; or 

b) Dynamic Configuration. 

The choice between a) and b) depends upon operators' preferences or roaming agreement or both. 

6.3.2 Static configuration of inter-access mobility mechanism 

For networks deploying a single IP mobility management mechanism, the statically configured mobility mechanism can 
be access type or roaming agreement specific or both. The information about the mechanism to be used in such scenario 
is expected to be provisioned into the terminal and the network. 

In static configuration, if there is a mismatch between the IP mobility mode mechanism parameters pre-configured in 
the network and in the UE, the UE may not be able to access the EPC. If the UE is able to access the EPC even if there 
is a mismatch between the IP mobility mode mechanisms, the network may not be able to provide session continuity for 
the UE. More details of the possible cases of mismatch between the IP mobility mode mechanism are described in the 
informative annex D. 

If the network is configured with a static mobility mechanism and the AAA server implements protocol extensions for a 
dynamic IP Mobility Mode Selection (IPMS) exchange, the AAA server shall send to the UE an AT_RESULT_IND 
attribute during the authentication procedure as it is described in subclause 6.3.3.1.2. 

6.3.3 Dynamic configuration of inter-access mobility mechanism 

6.3.3.0 General 

Dynamic IP Mobility Mode Selection (IPMS) consists of: 

IP mobility management protocol selection between Network Based Mobility (NBM), DSMIPv6 or MIPv4; and 

Decision on IP address preservation if NBM is selected 

Upon initial attachment to a non-3GPP access and upon handoff to non-3GPP accesses, the UE performs IPMS by 
providing an indication during network access authentication for EPC. For trusted access, the indication is provided 
before an IP address is allocated to the UE, while in untrusted access network, the indication is provided during IKEv2 
signalling for IPSec tunnel establishment with the ePDG. 

When the UE provides an explicit indication for IPMS, then the network shall provide the indication to the UE 
identifying the selected mobility management mechanism. 

When the dynamic IP mobility mode selection is used if the UE does not receive any indication of a selected mobility 
protocol after the UE provided an explicit indication, it is considered as an abnormal case and the UE may not get 
connectivity to the EPC. 

NOTE: The scenarios for mobility mode selection are described in subclause 4. 1.3 of 3GPP TS 23.402 [6]. 

6.3.3.1 IPMS indication 

6.3.3.1 .1 IPMS indication from UE to 3GPP AAA server 

During network access authentication, UE may provide an explicit indication to the 3GPP AAA server about the 
supported mobility protocol by using an attribute in the EAP-AKA and EAP-AKA' protocols, to extend these protocols 
as specified in subclause 8.2 of IETF RFC 4187 [33]. This attribute is provided in EAP-Response/AKA-Challenge and 
corresponding EAP-AKA' message payload. 
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The UE may provide the indication for IPMS using AT_IPMS_IND attribute in EAP-AKA or EAP-AKA' if the UE 
receives the AT_RESULT_IND attribute within the EAP-Request/AKA-Challenge message, or the EAP- 
Request/AKA'-Challenge message (when EAP-AKA' is used). If the UE provides the AT_IPMS_IND attribute within 
the EAP-Response/AKA-Challenge message payload or within the EAP-Response/AKA'-Challenge message payload 
(when EAP-AKA' is used), the UE shall also provide the AT_RESULT_IND attribute within the message. 

If the UE supports IPMS indication, it shall indicate support for one or more mobility protocols in AT_IPMS_IND 
attribute as follows: 

- the UE shall indicate support for DSMIPv6 if the UE supports DSMIPv6; and 

the UE shall indicate support for MIPv4 if the UE supports MIPv4; and 

during initial attach, the UE should indicate support for NBM if the UE supports address preservation based on 
NBM between the access it is attaching to and all other accesses that the UE supports.; or 

upon handover, the UE shall indicate support for NBM if the UE supports address preservation based on NBM 
while moving from source access network to target non-3GPP access network that the UE is attaching to. 

If the UE does not support any mobility protocol then the UE shall not send the AT_IPMS_IND attribute to the 3GPP 
AAA server. 

The preference of protocol may be indicated based on the policies configured on the UE. The detailed coding of this 
attribute is described in subclause 8.2.1.1. 

6.3.3.1 .2 IPMS indication from 3GPP AAA server to UE 

A 3GPP AAA server supporting IPMS shall include the AT_RESULT_IND attribute within the EAP-Request/AKA- 
Challenge and corresponding EAP-AKA' message payload. 

If the UE provided an explicit indication as described in subclause 6.3.3, the 3GPP AAA server shall inform the UE of 
its decision on the mobility protocol and IP preservation mode by invoking an EAP-Request/AKA-Notification 
dialogue when EAP-AKA is used or an EAP -Request/ AKA'-Notification dialogue when EAP-AKA' is used. 

On selecting the mobility protocol based on UE indication, access network capabilities and network policies, the 3GPP 
AAA server shall indicate the selected protocol to the UE by using the AT_IPMS_RES attribute. If the 3GPP AAA 
server does not receive any indication from the UE but knows the UE's policies allow the usage of NBM and knows the 
home and access network supports NBM, the network shall use NBM shall be used for providing connectivity to the 
UE. 

If the AT_IPMS_RES attribute indicates DSMIPv6 then the UE shall follow the procedures defined in 
3GPPTS 24.303 [11]. 

If the AT_IPMS_RES attribute indicates MIPv4 support, then the UE shall follow the procedures defined in 

3GPPTS 24.304 [12]. 

The detailed coding of this attribute is described in subclause 8.2.1.2. 

6.4 Authentication and authorization for accessing EPC via a 
trusted non-3GPP access network 

6.4.1 General 

For access to the EPC via a trusted non-3GPP access network, a connection shall be established between the UE and the 
trusted non-3GPP access network using signalling procedures specific to the trusted non-3GPP access network, which 
are out of scope of this present document. 

Access authentication signalling for access to the EPC shall be executed between the UE and 3GPP AAA server to 
ensure mutual authentication of the user and the EPC, with the exception of UEs without IMSI (see subclauses 4.4. 1 
and 6.6.3.2). Such authentication is based on IETF protocols as specified in 3GPP TS 33.402 [15]. 
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EAP-AKA' is used for access authentication in the trusted access network, according to 3GPP TS 33.402 [15], 
subclause 6.2. According to 3GPP TS 33.402 [15], subclause 6.1, EAP-AKA' can be skipped if conditions listed in 
subclause 9.2.2.1 of 3GPP TS 33.402 [15] are met. 

If the access network does not support EAP-AKA or EAP-AKA' and the UE considers the access network as trusted, 
the UE shall access to the EPC only via S2c and any authentication method (EAP -based or otherwise) can be used for 
access authentication as long as the criteria set in 3GPP TS 33.402 [15], subclause 9.2.2.1 are met. 

During S2c bootstrapping EAP-AKA authentication is performed between the UE and the PDN-GW as specified in 
3GPP TS 24.303 [11] and 3GPP TS 33.402 [15]. 

6.4.2 UE procedures 

6.4.2.1 Identity Management 

The user identities to be used by the UE in the authentication and authorization for accessing EPC via a trusted non- 
3GPP access are the Root-NAl (permanent identity), decorated NAl, Fast-Reauthentication NAJ (Fast-Reauthentication 
Identity) and Pseudonym Identity and these identities are described in subclause 4.4. 

6.4.2.2 EAP-AKA and EAP-AKA' based Authentication 

The UE shall support EAP-AKA based authentication as specified in IETF RFC 4187 [33] and EAP-AKA' based 
authentication as specified in IETF RFC 5448 [38]. 3GPP TS 33.402 [15] specifies the conditions under which one or 
the other of these two methods is used. 

During network access authentication, the UE may provide an explicit indication for IPMS by adding an attribute in the 
EAP-AKA or EAP-AKA' payload as defined in subclause 6.3.3. 

During network access authentication, the 3GPP AAA server may provide the ANID to the UE, see subclause 6.4.2.4. 

6.4.2.3 Full Authentication and Fast Re-authentication 

The UE shall support both full authentication and fast re-authentication for EAP AKA as specified in 
IETF RFC 4187 [33] and for EAP-AKA' as specified in IETF RFC 5448 [38]. 

Full authentication is performed to generate new keys. The initial authentication shall be a full authentication as 
specified in 3GPP TS 33.402 [15]. For a full authentication either the Permanent Identity or the Pseudonym Identity is 
used. 

According to 3GPP TS 33.402 [15] the fast re-authentication procedure uses the Fast Re-authentication Identity and is 
used for renewing the session keys. 

The Permanent Identity is based on the IMSI of the UE. The Fast Re-authentication Identity is provided to the UE by 
the 3GPP AAA server during the previous authentication procedure. The UE shall use the Fast Re-authentication 
Identity only once. A Pseudonym Identity provided to the UE by the 3GPP AAA Server during a previous 
authentication procedure can be reused in later authentications until the UE receives a new Pseudonym identity from the 
3GPP AAA Server. 

NOTE: The 3GPP AAA Server will assign a new Pseudonym Identity with a frequency dictated by operator's 

policy. The allocation of new pseudonyms is required to prevent that the user's movements are tracked by 
an unauthorized party. 

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message containing 
AT_PERMANENT_ID_REQ, the UE shall return the Permanent Identity in the ATJDENTITY attribute of the EAP- 
Response/AKA_ldentity. If the UE receives an EAP-Request/AKA'-Identity message containing 
AT_PERMANENT_1D_REQ, the UE shall return the Permanent Identity in the ATJDENTITY attribute of the EAP- 
Response /AKA' -Identity message. 

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message which contains 
AT_FULLAUTH_ID_REQ, the UE shall return the Pseudonym Identity as the ATJDENTITY within EAP- 
Response/AKA_Identity message if available. If the UE receives an EAP-Request/AKA' -Identity message containing 
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AT_FULLAUTH_ID_REQ, the UE shall return the Pseudonym Identity as the ATJDENTITY within the EAP- 
Response /AKA'-Identity message if available. Otherwise the UE shall return the Permanent Identity. 

If during an authentication request, the UE receives an EAP-Request/AKA-Identity message or EAP-Request/ AKA'- 
Identity message respectively, which contains AT_ANY_ID_REQ, the UE shall return the Fast Re-authentication 
Identity if available as the AT_IDENTITY. Otherwise the UE shall return the Pseudonym Identity. 

6.4.2.4 Handling of the Access Network Identity 

6.4.2.4.1 General 

The 3GPP AAA server provides the UE with the ANID in EAP signalling. The UE can also obtain the ANID by access 
network specific means, which are out of scope of the present document. For some access networks the ANID can also 
be configured into the UE and the 3GPP AAA server. 

NOTE: According to 3GPP TS 33.402 [15], the ANID is used by HSS and UE to generate transformed 

authentication vectors and therefore the ANID needs to be identical in the HSS and in the UE. The trusted 
non-3GPP access network first sends the ANID to the 3GPP AAA server via the STa reference point and 
the 3GPP AAA server sends the ANID to HSS via the SWx reference point, see 3GPP TS 29.273 [17], 
and to the UE as specified in this specification. 

6.4.2.4.2 ANID indication from 3GPP AAA server to UE 

When the 3GPP AAA server sends an EAP Request' or AKA-Challenge' message to the UE, the 3GPP AAA server 
shall include the ANID to be used when generating transformed authentication vectors, using the AT_KDF_INPUT 
attribute as described in subclause 8.2.2. The value and coding of this attribute is described in subclause 8.1.1. 

6.4.2.4.3 UE check of ANID for HRPD CDMA 2000® access networks 

The UE shall apply the rules for comparison of the locally determined ANID and the one received over EAP-AKA' as 
specified in IETF RFC 5448 [38]. The UE, or the user, may use the ANID as a basis for an optional decision whether 
the access network is authorized to serve the UE. E.g. the UE may compare the ANID against a list of preferred or 
barred ANIDs. 

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a 
eHRPD network, the locally determined ANID is "HRPD". If the comparison check is successful and if either the 
optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; 
otherwise the UE shall abort the access procedure. 

6.4.2.4.4 UE check of ANID for WiMAX access networks 

The UE shall apply the rules for comparison of the locally determined ANID and the one received over EAP-AKA' as 
specified in IETF RFC 5448 [38]. The UE, or the user, may use the ANID as a basis for an optional decision whether 
the access network is authorized to serve the UE. E.g. the UE may compare the ANID against a list of preferred or 
barred ANIDs. 

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a 
WiMAX access network, the locally determined ANID is "WIMAX". If the comparison check is successful and if either 
the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; 
otherwise the UE shall abort the access procedure. 

6.4.2.4.5 UE check of ANID for WLAN access networks 

The UE shall apply the rules for comparison of the locally determined ANID and the one received over EAP-AKA' as 
specified in IETF RFC 5448 [38]. The UE, or the user, may use the ANID as a basis for an optional decision whether 
the access network is authorized to serve the UE. E.g. the UE may compare the ANID against a list of preferred or 
barred ANIDs. 

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a 
WLAN network, the locally determined ANID is "WLAN". If the comparison check is successful and if either the 
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optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; 
otherwise the UE shall abort the access procedure. 

6.4.2.4.6 UE check of ANID for ETHERNET access networks 

The UE shall apply the rules for comparison of the locally determined ANID and the one received over EAP-AKA' as 
specified in IETF RFC 5448 [38]. The UE, or the user, may use the ANID as a basis for an optional decision whether 
the access network is authorized to serve the UE. E.g. the UE may compare the ANID against a list of preferred or 
barred ANIDs. 

When the UE can locally determine based on physical layer or access network procedures that the UE is connected to a 
Ethernet network, the locally determined ANID is "ETHERNET". If the comparison check is successful and if either 
the optional access network authorization decision in the UE is positive or is not performed, the UE shall proceed; 
otherwise the UE shall abort the access procedure. 

6.4.2.5 Full name for network and short name for network 

When receiving the EAP-Request/AKA-Challlenge message when the EAP-AKA is used or the EAP-Request/AKA'- 
Challlenge message when the EAP-AKA' is used, and the AT_FULL_NAME_FOR_NETWORK attribute, the 
AT_SHORT_NAME_FOR_NETWORK attribute or both are included, then the UE may use the contents to update 
appropriate information stored within the UE. 

6.4.3 3GPP AAA server procedures 

6.4.3.1 Identity Management 

The 3GPP AAA selects the pseudonym identity or the Fast Re-authentication Identity and returns the identity to the UE 
during the Authentication procedure as specified in 3GPP TS 33.402 [15]. The 3GPP AAA server shall maintain a 
mapping between the UE's permanent identity and the pseudonym identity and between the UE's permanent identity and 
the Fast Re-authentication Identity. 

6.4.3.2 EAP-AKA and EAP-AKA' based Authentication 

The 3GPP AAA server shall support EAP AKA based authentication as specified in IETF RFC 4187 [33] and EAP- 
AKA' based authentication as specified in IETF RFC 5448 [38]. 3GPP TS 33.402 [15] specifies the conditions under 
which one or the other of these two methods is used. If the UE provides an explicit indication for the supported mobility 
protocols and the network supports multiple IP mobility mechanisms, the network shall select the protocol to be used 
and communicate the decision to the UE as defined in subclause 6.3.3.1.2. 

6.4.3.3 Full authentication and Fast Re-authentication 

The 3GPP AAA shall support full re-authentication and fast re-authentication as specified in IETF RFC 4187 [33]. 

The decision to use the fast re-authentication process is taken by the home network (i.e. the 3GPP AAA server) and is 
based on operator policies. If fast re-authentication is to be used, the home network shall indicate this to the UE by 
providing the Fast Re-authentication Identity to the UE during the authentication process. 

When initiating an authentication, the home network shall indicate the type of authentication required by including 
either AT_PERMANENT_ID_REQ or AT_FULLAUTH_ID_REQ for Full authentication and AT_ANY_ID_REQ for 
Fast re-authentication in the EAP-Request/AKA_Identity message or the EAP-Request/AKA'-Identity message 
respectively. 

The home network (i.e. the 3GPP AAA server) may upon receiving the Fast Re-authentication Identity in 
AT_IDENTITY, decide to proceed with the fast re-authentication or choose instead to initiate a full authentication. This 
decision is based on operator policies. 
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6.4.3.4 Full name for network and short name for network 

The 3GPP AAA server may include the AT_FULL_NAME_FOR_NETWORK attribute, the 
AT_SHORT_NAME_FOR_NETWORK attribute or both in the EAP -Request/ AKA-Challlenge message when the 
EAP-AKA is used and in the EAP-Request/AKA'-Challlenge message when the EAP-AKA' is used. 

The detailed coding of the AT_FULL_NAME_FOR_NETWORK attribute and the 
AT_SHORT_NAME_FOR_NETWORK is described in subclause 8.2.5. 

6.4.4 Multiple PDN support for trusted non-3GPP access 

Connectivity to multiple PDNs via trusted non-3GPP access is supported in the EPS when the network policies, the 
non-3GPP access and the user subscription allow it. 

NOTE 1 : In 3GPP, there is a limitation to the maximum number of simultaneous PDN connections per UE which 
is 1 1 (caused by the EPS bearer identity, see 3GPP TS 24.007 [48]). Not complying with this limitation 
when accessing non-3GPP access can lead to unexpected consequences, e.g. connectivity loss in case of 
handover to 3GPP access. 

If the UE supports dynamic mobility management selection the UE shall use the same mobility protocol when multiple 
connections are established, see 3GPP TS 23.402 [6]. 

When using the S2a interface to establish connections to additional PDNs the UE shall send a trigger for additional 
PDN connectivity specific to the non-3GPP access. The UE shall include an APN in this trigger to connect to the 
desired PDN. The UE shall also indicate the Attach Type to the trusted non-3GPP access during additional PDN 
connectivity. The Attach Type shall distinguish between Initial Attach and Handover Attach. 

NOTE 2: The indication about Attach Type is non-3GPP access network specific and its coding is out of scope of 
this specification. 

NOTE 3: The trigger for additional PDN connectivity is non-3GPP access network specific and its coding is out of 
scope of this specification. 

When using the S2c interface, the UE shall follow the procedures described in 3GPP TS 24.303 [11] to connect to 
multiple PDNs. 

If the UE is handing over from a source access network to a target non-3GPP access using S2a and the UE has more 
than one PDN connection to a given APN in the source access network, the UE shall transfer all the PDN connections 
for the given APN to the target trusted non-3GPP access network as specified in 3GPP TS 23.402 [6]. 

If multiple PDN connections to a single APN are not supported over the target trusted non-3GPP access network, only 
one PDN connection to the given APN shall be established in the target non-3GPP access as specified in 
3GPP TS 23.402 [6]. If multiple PDN connection requests to the same APN are received but the target trusted non- 
3GPP access network does not support multiple PDN connections to the same APN, the network shall reject the 
additional PDN connection requests to the same APN received from the UE when one PDN connection to the same 
APN has already been established. The UE shall determine which PDN connection is re-established in the non-3GPP 
access based on the home address information (i.e. IPv4 address or IPv6 prefix or both) provided by the network. 

NOTE 4: The protocol details of the PDN connection reject procedure is non-3GPP access network specific and its 
coding is outside the scope of this specification. 

NOTE 5: When UE supporting IP address preservation for NBM with multiple PDN connections to the same APN 
hands over to the non-3GPP access network, the UE can, as an implementation option, prioritise the re- 
establishment for a particular PDN connection before re-establishing the remaining PDN connections. 
The way a UE prioritizes a particular PDN connection is non-3GPP access network specific and its 
coding is out of scope of this specification. Another implementation option can be to send multiple re- 
establishment requests concurrently. 

NOTE 6: Any unsuccessful re-establishment of any of the multiple PDN connections to the same APN can be 

managed in an implementation specific manner avoiding UE making repeated re-establishment attempts 
to the network. 

If the UE did not handover all the PDN connections for a given APN to the target trusted non-3GPP access network, the 
network may disconnect the remaining PDN connections for that given APN after an implementation dependent time. 
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6.5 Authentication and authorization for accessing EPC via an 
untrusted non-3GPP access network 

6.5.1 General 

In order to attach to the evolved packet core network (EPC) via untrusted non-3GPP IP access, the UE first needs to be 
configured with a local IP address from the untrusted non-3GPP access network. 

During the attach to the untrusted non-3GPP access, the operator of the non-3GPP access network may optionally 
require toperform a 3GPP based access authentication as specified in 3GPP TS 33.402 [15]. 

Once the UE is configured with a local IP address, the UE shall select the Evolved Packet Data Gateway (ePDG) as 
described in subclause 7.2.1 and shall initiate the IPsec tunnel establishment procedure as described in subclause 7.2.2. 
During these steps authentication and authorization for access to EPC shall be performed. 

6.5.2 Full authentication and authorization 

6.5.2.1 General 

During the establishment of the IPSec tunnel between the UE and the ePDG, 3GPP based authentication signalling for 
untrusted non-3GPP access to the EPC shall be exchanged between the UE and the 3GPP AAA server in the EPC to 
ensure mutual authentication of the user and the EPC. 

Authorization of EPC access shall be performed by the 3GPP AAA server upon successful user authentication. 

The access authentication signalling between the UE and the 3GPP AAA server shall be based on EAP-AKA as 
specified in IETF RFC 4187 [33] and is further detailed in 3GPP TS 33.402 [15], 3GPP TS 29.273 [17] and procedural 
descriptions in subclauses 7.2.2 and 7.4.4. 

6.5.2.2 UE procedures 

When accessing the EPC via the ePDG, the UE shall exchange EAP-AKA signalling with the 3GPP AAA server as 
specified in 3GPP TS 33.402 [15]. 

NOTE: the EAP payload exchanged between UE and 3GPP AAA server is transported within the IKEv2 
messages exchanged with ePDG as described in subclause 7.2.2. 

6.5.2.3 3GPP AAA server procedures 

During the authentication of the UE for accessing the EPC via the ePDG, the 3GPP AAA server shall initiate EAP- 
AKA based authentication with the UE as specified in 3GPP TS 33.402 [15]. 

6.5.3 IVIultiple PDN support for untrusted non-3GPP access network 

Connectivity to multiple PDNs via untrusted non-3GPP access is supported in the EPS when the network policies, the 
non-3GPP access and the user subscription allow it. 

NOTE 1 : In 3GPP, there is a limitation to the maximum number of simultaneous PDN connections per UE which 
is 1 1 (caused by the EPS bearer identity, see 3GPP TS 24.007 [49]). Not complying with this limitation 
when accessing non-3GPP access can lead to unexpected consequences, e.g. connectivity loss in case of 
handover to 3GPP access. 

If the UE supports dynamic mobility management selection the UE shall use the same mobility protocol when multiple 
connections are established, see 3GPP TS 23.402 [6]. 

When using the S2b interface to establish additional PDN connections, the UE shall establish an IPSec tunnel with the 
same ePDG for each PDN connection. For each tunnel establishment procedure, the UE shall indicate to the ePDG an 
APN to the desired PDN and an attach type indication as specified in subclause 7.2.2. 
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When using the S2c interface, the UE shall follow the procedures described in 3GPP TS 24.303 [11] when establishing 
multiple PDN connections. For multiple PDN connections over the S2c interface, the UE shall establish only one IPsec 
tunnel to the ePDG. 

If the UE had more than one PDN connection to a given APN in the source access network and the UE is performing a 
handover to a target untrusted non-3GPP access network via an ePDG that supports the S2b interface, the UE shall 
transfer all the PDN connections for the given APN to the target untrusted non-3GPP access network as specified in 
3GPPTS 23.402 [6]. 

If multiple PDN connections to a single APN are not supported over the target untrusted non-3GPP access network, 
only one PDN connection to that given APN shall be established in the target non-3GPP access network as specified in 
3GPP TS 23.402 [6] if NBM is used. The UE, if supporting IP address preservation for NBM, shall include the home 
address information during the tunnel establishment procedure as specified in subclause 7.2.2. If multiple PDN 
connection requests to the same APN are received but the network does not support multiple PDN connections to the 
same APN, the ePDG shall reject the additional PDN connection requests to the same APN received from the UE as 
described in subclause 7.4.1, in the following circumstances: 

when one PDN connection to the same APN has already been established; 

only after the network has successfully established one PDN connection in the case that the additional PDN 
connections requests were received prior to the successful establishment of a single PDN connection. 

In the above cases, the UE shall determine which PDN connection is re-established in the non-3GPP access based on 
the home address information provided by the network. 

The UE behaviour, when PDN connection re-establishment is rejected by the network during handover to the untrusted 
non-3GPP access network, is described in sublause 7.2.2. 

NOTE 2: When a UE supporting IP address preservation for NBM with multiple PDN connections to the same 

APN hands over to the non-3GPP access network, the UE can, as an implementation option, prioritise the 
re-establisment for a particular PDN connection before re-establishing the remaining PDN connections. 
The UE indicates the prioritised PDN connection by including both the APN in the IDr payload and the 
home address information in the Handover Attach indicator as specified in subclause 7.2.2. Another 
implementation option can be to send multiple re-establishment requests concurrently. 

If the UE did not handover all the PDN connections for a given APN to the target untrusted non-3GPP access network, 
the network may disconnect the remaining PDN connections for that given APN after an implementation dependent 
time. 

6.6 UE - 3GPP EPC (cdma2000® HRPD Access) 
6.6.1 General 

3GPP2 X.S0057 [20] defines the interworking architecture for access to the EPC via cdma2000® HRPD access 
networks. In particular, 3GPP2 X.S0057 [20] describes support 
access the EPC architecture defined in 3GPP TS 23.402 [6] by: 



networks. In particular, 3GPP2 X.S0057 [20] describes support for a UE using the cdma2000® HRPD air interface to 



specifying the use of the interface across the S2a reference point between the 3GPP2 HRPD Serving Gateway 
(HSGW) and the PDN Gateway (P-GW) in the EPC by referencing 3GPP TS 29.275 [18]; 

specifying the use of the interface across the SlOl reference point between the eAN/PCF in the 3GPP2 HRPD 
access network and the MME in the EPC by referencing 3GPP TS 29.276 [19]; 

specifying the use of the user plane interface across the S 103 reference point between the EPC Serving Gateway 
(S-GW) and the HSGW by referencing 3GPP TS 29.276 [19]; and 

describing the internal functions and responsibilities of the HSGW. 

3GPP2 C.S0087 [21] defines the signalling requirements and procedures for UEs accessing the EPC via 3GPP2 HRPD 
access networks using the cdma2000® HRPD air interface. In particular, 3GPP2 C.S0087 [21]: 

defines the signalling extensions to the cdma2000® HRPD air interface defined in 3GPP2 C.S0024 [23] 
necessary to support interworking with the EPC and E-UTRAN; and 
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defines the UE and eAN/PCF procedures and signalling formats to support bidirectional handoff between 
E-UTRAN and cdma2000® HRPD. 

6.6.2 Non-emergency case 

6.6.2.1 General 

Subclauses 6.6.2.2 through 6.6.2.7 describe the particular requirements for access to the EPC via a cdma2000® HRPD 
access network in support of non-emergency accesses and services. 

6.6.2.2 UE identities 

The UE and network shall use the root NAI as specified in 3GPP TS 23.003 [3] for EPC access authentication when the 
UE obtains service via a cdma2000® HRPD access network connected to an EPC in the UE's HPLMN. 

Additionally, the UE and network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described in 
subclause 4.4. 

6.6.2.3 cdma2000® HRPD access network identity 

The access network identity is described in 3GPP TS 23.003 [3] and in subclause 6.4.2.4 of this specification. For a 
cdma2000® HRPD network, the value and encoding of the access network identity is described in subclause 8.1.1. The 
3GPP AAA server, HSS, and any visited network AAA proxy shall use the access network identity during EAP-AKA' 
authentication procedures (see 3GPP TS 33.402 [15]). 

6.6.2.4 PLIVIN system selection 

The UE shall rely on information provisioned by the home operator to facilitate the PLMN system selection process 
described in 3GPP TS 23.122 [4]. 

6.6.2.5 Trusted and untrusted accesses 

The UE shall determine the trust relationship for access to the EPC via a cdma2000® HRPD access network as 
described in subclause 4. 1 . 

6.6.2.6 IP mobility mode selection 

The UE and network shall perform IP mobility mode selection as described in subclauses 6.3.3.1 and 6.4.3.2 

6.6.2.7 Authentication and authorization for accessing EPC 

The UE and 3GPP AAA server shall perform authentication and authorization procedures for access to the EPC as 
defined in 3GPP TS 33.402 [15]. 

6.6.3 Emergency case 

6.6.3.1 General 

Subclauses 6.6.3.2 through 6.6.3.3 describe the particular requirements for access to the EPC via a cdma2000® HRPD 
access network in support of an emergency session in course of handover from E-UTRAN to HRPD. 

In this release of the specification no emergency session related handling other than the handover of an emergency 
session from E-UTRAN to an S2a based cdma2000® HRPD access network is specified. 

6.6.3.2 UE identities 

When the UE obtains emergency services via a cdma2000 " HRPD access network connected to an EPC in the UE's 
HPLMN, then the UE and the network shall use the NAI for EPC access authentication as follows: 
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if IMSI is available and authenticated , then the UE and the network shall use the root NAI as specified in 
3GPPTS 23.003 [3]; 

if IMSI is not available or unauthenticated, then the emergency NAI as specified in 3GPP TS 23.003 [3] shall be 
used. 

Additionally, the UE and the network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described 
in subclause 4.4.1. 

6.6.3.3 Authentication and authorization for accessing EPC 

If IMSI is available, then the authentication and authorization procedures via STa are executed if the local regulation 
and network operator option requires authenticating the UE. 

If the authentication and authorization procedures fail, then it depends on local regulation and network operator option 
to allow or reject the emergency services for the UE. 

If IMSI is not available, the authentication and authorization procedures via STa are not executed. 

6.7 UE - 3GPP EPC (WiMAX Access) 

6.7.1 General 

The WiMAX system and its access network subsystem are described within WiMAX Forum Network Architecture 
Release 1.0 version 1.2 - Stage 2 [24]. The protocol architecture and signalling of the WiMAX system is specified in 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25]. This protocol architecture and signalling 
supports the air interface defined in WiMAX Forum Mobile System Profile Release 1 .0 Approved Specification 
Revision 1.4.0 [26] which specifies selected profiles of IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Corl- 
2005 [27]. 

6.7.2 Non-emergency case 

6.7.2.1 General 

Subclauses 6.7.2.2 through 6.7.2.7 describe the particular requirements for access to the EPC via a WiMAX access 
network in support of non-emergency accesses and services. 

6.7.2.2 UE identities 

The UE and network shall use the root NAI as specified in 3GPP TS 23.003 [3] for EPC access authentication when the 
UE obtains service via a WiMAX access network connected to an EPC in the UE's HPLMN. 

Additionally, the UE and network shall use the Fast-Reauthentication NAI and the Pseudonym Identity as described in 

subclause 4.4. 

6.7.2.3 WilVlAX access networl^ identity 

The access network identity is described in 3GPP TS 23.003 [3] and in subclause 6.4.2.4 of this specification. For a 
WiMAX network, the value and encoding of the access network identity is described in subclause 8.1.1. The 3GPP 
AAA server, HSS, and any visited network AAA proxy shall use the access network identity during EAP-AKA 
authentication procedures (see 3GPP TS 33.402 [15]). 

6.7.2.4 Selection of the Network Service Provider 

The UE shall use WIMAX-specific procedures described in WiMAX Forum Network Architecture Release 1 .0 version 
1.2 - Stage 3 [25] to discover and select the highest priority Network Service Provider (NSP) which is available and 
allowable. 
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6.7.2.5 Trusted and untrusted accesses 

The UE shall determine the trust relationship for access to the EPC via a WiMAX access network as described in 
subclause 4. 1 . 

6.7.2.6 IP mobility mode selection 

The UE and network shall perform IP mobility mode selection as described in subclauses 6.3.3.1 and 6.4.3.2. 

6.7.2.7 Authentication and authorization for accessing EPC 

NOTE: In line with 3GPP TS 33.402 [15], in this present specification, no particular security provisions are 
specified for interworking between WiMAX and EPS. Any access specific security procedures for 
WiMAX as a non-3GPP access network to EPC will be in accordance with 
WiMAX Forum Network Architecture Release 1.0 version 1.2 - Stage 3 [25] and 
WiMAX Forum Mobile System Profile Release 1.0 Approved Specification Revision 1.4.0 [26]. 

6.7.3 Emergency case 

NOTE: Procedures for handling emergency accesses or services are not specificed within this release of the 
specification 

6.8 Communication over the S1 4 
6.8.1 General 

In order to assist the UE with performing access network discovery and selection, ANDSF provides a set of information 
to the UE. This information contains the access network discovery and selection information to assist the UE with 
selecting the access network or the inter-system mobility policy to control and assist the UE with performing the inter- 
system change or both. This information also contain ISRP information to control and assist a UE configured for IFOM, 
or MAPCON or both with selecting the access network to be used for routing different IP flows or establishing PDN 
connections or both. Additionally, the ISRP provided by ANDSF can include information for identifying IP flows 
applicable for non-seamless offload to WLAN for a UE supporting this optional capability. 

This set of information can either be provisioned in the UE by the home operator, or provided to the UE by the ANDSF 
over the S14 reference point via pull or push mechanisms as defined in 3GPP TS 23.402 [6] by means of the access 
network discovery and selection procedures as described in subclause 6.8.2. While roaming, the UE can receive a set of 
information from H-ANDSF or V-ANDSF or both. 

The UE, located in the home PLMN, needs to discover the H-ANDSF by means of the discovery procedure as described 
in subclause 6.8.2.2.1. The UE, located in the visited PLMN, needs to discover the H-ANDSF or V-ANDSF or both by 
means of the discovery procedure as described in subclause 6.8.2.2.1. 

Through push mechanisms the ANDSF can provide assistance information to the UE e.g. if the UE has previously used 
pull based ANDSF procedure or if OMA-DM bootstrapping is used as described in subclause 6.8.2.2.1 A. Through pull 
mechanisms the UE can send a request to the ANDSF in order to get assistance information for access network 
discovery and selection. 

ANDSF shall comply with local, national and regional requirements regarding the privacy and confidentiality of 
location information. 

NOTE: The regulation and legislations of the home operator of the ANDSF server determines whether the 
ANDSF server can store the user's location information. 
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6.8.2 Interaction with tine Access Network Discovery and Selection 
Function 

6.8.2.1 General 

The S14 interface enables IP level communication between the UE and ANDSF. The protocols supported by the S14 
interface are realized above the IP level. Both pull and push mechanisms may be supported for communication between 
the UE and the ANDSF. A combination of pull and push mechanisms may also be supported. The communication 
security over the S14 interface is specified in 3GPP TS 33.402 [15]. 

The UE, located in a home PLMN, can communicate securely with the H-ANDSF. The UE, located in a visited PLMN, 
can communicate securely with H-ANDSF or V-ANDSF or both. 

The information is transferred between the UE and ANDSF using OMA DM as defined in OMA-ERELD-DM- 
Vl_2 [39] with the management object as specified in 3GPP TS 24.312 [13]. 

6.8.2.2 UE procedures 

6.8.2.2.1 UE discovering the ANDSF 

The UE shall support DNS lookup by name as specified in IETF RFC 1035 [35] to discover the IP address of ANDSF. 
Additionally, the UE may support DHCP query as specified in IETF RFC 6153 [37] to discover the IP address of H- 
ANDSF. 

The IP address of the H-ANDSF can be provisioned in the UE by the home operator. If not provisioned in the UE, for 
the case of a UE located in a home PLMN or an equivalent HPLMN, the IP address of the H-ANDSF can be discovered 
by the UE using a DHCP query as specified in IETF RFC 6153 [37]. The H-ANDSF IP address by which the UE can 
contact the H-ANDSF can also be obtained by the UE through a DNS lookup by name as specified in 
IETF RFC 1035 [35]. The QNAME shall be set to the ANDSF-SN FQDN, as defined in 3GPP TS 23.003 [3]. 

The V-ANDSF IP address by which the UE can contact the V-ANDSF is obtained by the UE through a DNS lookup by 
name as specified in IETF RFC 1035 [35]. The QNAME shall be set to the ANDSF-SN FQDN, as defined in 
3GPPTS 23.003 [3]. 

When the UE is in its HPLMN or equivalent HPLMN, the UE may use either DNS lookup or DHCP query to discover 
the IP address of the H-ANDSF. If the UE implements DHCP query, the following apply: 

The preference between DNS lookup and DHCP query is UE implementation dependent; and 

If the UE is unable to discover the IP address of the H-ANDSF using one discovery method, the UE may try to 
use the other discovery method. 

When the UE is in a visited PLMN, the UE shall use DNS lookup to discover the IP address of the ANDSF. 

When performing a DNS lookup resolution, the UE shall apply the following procedures: 

For the H-ANDSF discovery, the UE shall build a Fully Qualified Domain Name (FQDN) as defined in 
3GPP TS 23.003 [3] for the DNS request and select the IP address of the H-ANDSF included in the DNS 
response message. 

For the V-ANDSF discovery, the UE shall build a Fully Qualified Domain Name (FQDN) as defined in 
3GPP TS 23.003 [3] for the DNS request and select the IP address of the V-ANDSF included in the DNS 
response message. 

When performing a DHCP query resolution, for the case of a UE located in a home PLMN or an equivalent HPLMN, 
the UE shall send a DHCP message with the required DHCP option, as specified in IETF RFC 6153 [37], that allows 
the UE to discover the IP address of the H-ANDSF. 
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6.8.2.2.1 A ANDSF communication security 

According to 3GPP TS 33.402 [15], for the pull model, the UE and ANDSF shall use PSK TLS with GBA based shared 
key-based mutual authentication to establish a secure connection between UE and ANDSF as specified by subclause 5.4 
of 3GPPTS 33.222 [44]. 

According to 3GPP TS 33.402 [15], for the push model, the UE and ANDSF shall use PSK TLS with GBA push based 
shared key-based mutual authentication to establish a secure connection between the UE and the ANDSF as specified 
by subclause 5.1 of 3GPP TS 33.223 [47]. 

In accordance with 3GPP TS 29.109 [43], the BSF shall provide either the UE's IMSI or IMPI to NAF, ie the ANDSF 
server. 

OMA-DM's application level authentication mechanism does not need to be used with ANDSF, since mutual security 
association is already established on transport level using PSK-TLS as specified in 3GPP TS 33.402 [15]. According to 
OMA-ERELD-DM-Vl_2 [39], however, each Managed Object (MO) shall have an access control list (ACL) that lists 
authorized OMA DM servers. In order to comply with OMA-ERELD-DM-Vl_2 [39], the ANDSF-SN FQDN shall be 
used as server name in the ACL list. 

If the UE does not support the ANDSF security mechanism as specified in 3GPP TS 33.402 [15], or if the operator does 
not implement the GAA bootstrap framework specified in 3GPP TS 33.220 [42], appropriate communication security 
can be established with the ANDSF using OMA-DM's bootstrap, secure http (https) mechanism and WAP Push 
according to OMA-ERELD-DM-Vl_2 [39]. 

6.8.2.2.2 Role of UE for Push model 

The UE shall implement the push model of ANDSF in accordance with OMA-ERELD-DM-Vl_2 [39] using WAP 
Push, which is applicable for 3GPP access networks only. 

In the push model of communication, if the UE receives a notification SMS from the ANDSF, the UE shall establish a 
secure data connection using the information received in the notification SMS. 

In the push model of communication, if the UE receives a SMS message containing a GBA Push Information as 
specified in 3GPP TS 33.223 [47] from the ANDSF, the UE shall establish a secure data connection to the ANDSF 
using the GBA Push Information. If the UE does not understand the contents of the SMSfrom the ANDSF, the UE shall 
follow the pull model procedure as specified in subclause 6.8.2.2. lA to estabhsh a secure data connection with the 
ANDSF. 

Upon establishing a secure connection between the UE and ANDSF, the UE may be provided with updated inter-system 
policy, information about available access networks and ISRP. The list of the information is described in 
subclause 6.8.2.3.3 and the correspondent ANDSF MO is defined in 3GPP TS 24.312 [13]. 

A UE that is capable of IFOM or MAPCON or non-seamless WLAN offload or any combination of these capabilities, 
can be configured to support one or more of these capabilities (i.e. enable or disable one or more of these capabilities). 

The ANDSF may provide a list of Inter-System Routing Policies to a UE independent of the UE's capability of routing 
IP traffic simultaneously over multiple radio access interfaces. When a UE capable of any combination of IFOM or 
MAPCON or non-seamless WLAN offload has all those capabilities disabled, the UE shall not apply the Inter-System 
Routing Policies received from the ANDSF. 

6.8.2.2.3 Role of UE for Pull model 

In the pull model of communication, the UE sends a query to ANDSF to retrieve or update inter-system mobility policy 
or information about available access networks in its vicinity or both. A UE capable of IFOM or MAPCON or both may 
also request ISRP. As a result of the ISRP request, a non-seamless WLAN offload capable UE may also obtain 
information used to identify IP flows permissible for non-seamless offload to a WLAN. The UE will wait for an 
implementation dependent time for an answer from the ANDSF. If ANDSF does not respond within that time, further 
action by the UE is implementation dependent. The UE may provide to ANDSF the UE's location information 
including, if available, the location parameters (for example, cell identities or the MAC address of the WLAN AP) 
associated with the Radio Access Networks the UE has discovered in its current location at the time the UE sends a 
query to ANDSF; the format of the location information is described as UE_Location in ANDSF MO defined in 
3GPPTS 24.312 [13]. 
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After communicating with ANDSF, the UE may be provided with updated inter-system policy and information about 
available access networks. The list of the information is described in subclause 6.8.2.3.3 and the correspondent ANDSF 
MO is defined in 3GPP TS 24.312 [13]. 

The UE may start Pull model communication with ANDSF based upon the information previously received from the 
ANDSF (e.g. based on the value of UpdatePoHcy leaf defined in 3GPP TS 24.312 [13]). The UE capable of IFOM, 
MAPCON, or non-seamless WLAN offload (or any combination of these capabilities) can have all these capabilities 
disabled and have no ISRP. If the UE enables one (or more) of these capabilities, the UE may start Pull model 
communication with ANDSF. The UE capable of IFOM, MAPCON, or non-seamless WLAN offload (or any 
combination of these capabilities) can have one (or more) of these capabilities enabled and have no ISMP. If the UE 
disables all these capabilities, the UE may start Pull model communication with ANDSF. 

NOTE: Mechanisms to limit the frequency of queries transmission from the UE to the ANDSF are 
implementation dependant. 

A UE that is capable of IFOM or MAPCON or non-seamless WLAN offload or any combination of these capabilities, 
can be configured to support one or more of these capabilities (i.e. enable or disable one or more of these capabilities). 

The ANDSF may provide a list of Inter-System Routing Policies to a UE independent of the UE's capability of routing 
IP traffic simultaneously over multiple radio access interfaces. When a UE capable of any combination of IFOM or 
MAPCON or non-seamless WLAN offioad has all those capabilities disabled, the UE shall not apply the Inter-System 
Routing Policies received from the ANDSF. 

6.8.2.2.4 UE using information provided by ANDSF 

6.8.2.2.4.1 General 

Network detection and selection shall take into account the access network specific requirements and the UE's local 
policy, e.g. user preference settings, access history, etc, along with the information provided by the ANDSF when 
selecting an access network. The local policy and the information provided by the ANDSF shall be used by the UE in 
an implementation dependent way to limit the undesired alternating between access systems, e.g. ping-pong type of 
inter-system changes. However, the use of such information from the ANDSF shall not be in contradiction to functions 
specified in 3GPP TS 23.122 [4], 3GPP TS 24.234 [9], 3GPP TS 25.304 [14] and 3GPP TS 36.304 [16]. 

If the UE is roaming in a VPLMN, the UE may receive Inter-system mobility policies or Access network discovery 
information or ISRP or combinations of these from H-ANDSF or V-ANDSF or both. The formats of the Inter-system 
mobility policies. Access network discovery information and ISRP are defined in 3GPP TS 24.312 [13]. 

The maximum number of sets of Inter-system mobility polices or Access network discovery information or ISRP or 
combinations of these that the UE may keep is implementation dependent. However, the UE shall retain at least one set 
of Inter-system mobility policies and one set of Access network discovery information from the same ANDSF. In 
addition, an IFOM capable UE, MAPCON capable UE, or non-seamless WLAN offload capable UE shall retain at least 
one set of ISRP from the same ANDSF. 

For a UE with IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these capabilities) enabled, if 
ISMP and ISRP are available, then ISRP shall be used for the routing of IP traffic. The relation between ISRP and user 
preferences is described in subclause 5.4.2. 

For a UE not supporting any of IFOM, MAPCON or non-seamless offload capabilities or with all those capabilities 
disabled, if ISMP and ISRP are available, the ISMP shall be used. 

This information shall be deleted if there is a change of USIM. This information may be deleted when UE is switched 
off. 

6.8.2.2.4.2 Use of Inter-system Mobility Policy 

If more than one set of Inter-system mobility policies is available in the UE, the UE shall only use one set of Inter- 
system mobility policies at any one time. If available, the inter-system mobility policy of the RPLMN takes precedence. 
For example, when roaming, the Inter-system mobility policy from V-ANDSF of the RPLMN, if available, takes 
precedence over the Inter-system mobility policy from H-ANDSF. When applying the Inter-system mobility policy the 
following requirements apply :- 

the requirements on periodic network reselection as described in subclause 5.3.4 of the present specification; 
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- the PLMN selection rules specified in 3GPP TS 23.122 [4] and in 3GPP TS 24.234 [9]; 

- the selection rules specified in 3GPP2 C.P0016-D [23a]; and 

the 3GPP RAT selection, cell selection and reselection rules specified in 3GPP TS 25.304 [14], 
3GPP TS 36.304 [16] and 3GPP TS 45.008 [16a]. 

6.8.2.2.4.3 Use of Access Network Discovery Information 

The UE may use the received Access network discovery information of both the H-ANSDF and V-ANDSF for network 
discovery and detection. The Access network discovery information received from:- 

a) the H-ANDSF provides guidance for the UE on access networks that have connectivity to the HPLMN or 
equivalent HPLMNs or both; and 

b) the V-ANDSF provides guidance for the UE on access networks that have connectivity to the corresponding 
VPLMN or equivalent PLMNs or both. 

6.8.2.2.4.4 Use of Inter-System Routing Policies 

A UE that is configured for IFOM, MAPCON, or non-seamless WLAN offload (or any combination of these 
capabilities) shall use the ISRP if available. The ISRP if available in a UE that is not configured for IFOM capable, not 
configured for MAPCON, and not configured for non-seamless WLAN offload will be ignored by that UE. The ISRP if 
available in a UE capable of any combination of IFOM or MAPCON or non-seamless WLAN offload with all those 
capabilities disabled shall not be applied by that UE. 

A UE that is capable of IFOM or MAPCON or non-seamless WLAN offload or any combination of these capabilities, 
can be configured to support one or more of these capabilities (i.e. enable or disable one or more of these capabilities). 

A UE configured for IFOM uses the ISRP to: 

select an access technology or an access network or both for routing user plane traffic matching specific IP flows 
on a specific or any APN identified in the ISRP; and 

decide if an access technology or access network or both are restricted for a specific IP flows on a specific or any 
APN identified in the ISRP. 

A UE configured for MAPCON uses the ISRP to: 

select an access technology or an access network or both for routing user plane traffic matching a specific APN 
or any APN identified in the ISRP; and 

decide if an access technology or an access network or both are restricted for a specific APN or any APN 
identified in the ISRP. 

A UE configured for non-seamless WLAN offload uses the ISRP to: 

select a WLAN access network for routing, without traversing the EPC, user plane traffic matching specific IP 
flows for a specific APN or any APN identified in the ISRP; and 

decide if a WLAN access network is restricted for routing, without traversing the EPC, a specific IP flows for a 
specific APN or any APN identified in the ISRP. 

When the IFOM capable UE identifies an access technology or an access network or both over which an IP flow can be 
routed based on the ISRP, the IFOM configured for UE shall apply the IFOM procedures specified in 3GPP TS 
24.303 [11] to move an on-going IP flow from the source access technology or access network to the identified access 
technology or access network, if required. 

If more than one set of ISRP is available in the UE, the UE shall only use one set of ISRP at any one time. If available, 
the ISRP of the RPLMN takes precedence. When applying ISRP the same requirements defined for inter-system 
mobility policy in subclause 6.8.2.2.4.2 applies. 
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6.8.2.3 ANDSF procedures 

6.8.2.3.1 General 

Both the H- ANDSF and the V-ANDSF can provide information about inter-system mobility policy or information 
about available access networks in the vicinity of the UE or ISRP for the UE or combinations of these. The inter-system 
mobility policies may be organized in a hierarchy and a priority order among multiple policies may determine which 
policy has the highest priority. The policies may indicate preference of one access network over another or may restrict 
inter-system mobility to a particular access network under certain conditions. The ANDSF may also specify validity 
conditions which indicate when a policy is valid. Such conditions may be based on time duration, location, etc. The 
ANDSF may limit the information provided to the UE. This can be based on UE's current location, UE capabilities 
other than the capability of routing IP traffic simultaneously over multiple radio access interfaces (e.g. IFOM capability 
or MAPCON capability or non-seamless WLAN offload capability), etc. How the ANDSF decides how much 
information to provide to the UE is dependent on network implementation. 

6.8.2.3.2 Role of ANDSF for Push model 

If there is no existing valid PSK TLS connection between the UE and ANDSF, the ANDSF, not implementing GBA 
Push, may send a notification SMS to the UE, without establishing a data connection with the UE. 

If there is no existing valid PSK TLS connection between the UE and ANDSF, the ANDSF, implementing GBA Push, 
shall send a message via SMS to the UE to establish a secure connection between the UE and ANDSF. The contents of 
the message shall contain a GBA Push Information as specified in 3GPP TS 33.223 [47]. 

If there is an existing valid PSK TLS connection between the UE and ANDSF, the ANDSF shall use the existing 
connection to update the inter-system mobility policy in the UE or inform the UE about available access networks in the 
vicinity of the UE. 

After a secure connection is established according to subclause 6.8.2.2.1 A, the ANDSF may update the inter-system 
mobility policy or the ISRP in the UE or inform the UE about available access networks in the vicinity of the UE. 

6.8.2.3.3 Role of ANDSF for Pull model 

When contacted by UE, ANDSF may interact with the UE in order to provide the UE with inter-system mobility policy 
or information about available access networks in the vicinity of the UE or ISRP for the UE or combinations of these. In 
case of information about available access networks, the ANDSF provides the following information about each 
available access networks in the form of a list containing: 

1) Type of Access network (e.g. WLAN, WiMAX); 

2) Location of Access Network (e.g. 3GPP location, WLAN location); 

3) Access Network specific information (e.g WLAN information, WiMAX information); and 

4) Operator differentiated text field (if supported, e.g. if WNDS MO defined in 3GPP TS 24.312 [13] is used). 
The detailed list of information is described in 3GPP TS 24.312 [13]. 

6.9 Handling of Protocol Configuration Options information 

The Protocol Configuration Options (PCO) information element is specified in 3GPP TS 24.008 [46]. 

The support of PCOs is optional for the UE and the non-3GPP access network. 

The content syntax of PCOs for the non-3GPP access UE and non-3GPP access network is access network specific and 
not in the scope of 3GPP, but if PCO is supported, the UE and the PDN-GW shall handle the PCO contents in 
accordance with 3GPP TS 24.008 [46]. 

PCO information is exchanged between the UE and the PDN-GW, see 3GPP TS 23.402 [6] and 3GPP TS 29.275 [18]. 
The specification of PCO signalling in the non-3GPP access network is access network specific and not in the scope of 
3GPP. 
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Tunnel management procedures 



7.1 General 

The purpose of tunnel management procedures is to define the procedures for establishment or disconnection of an end- 
to-end tunnel between the UE and the ePDG. The tunnel establishment procedure is always initiated by the UE, whereas 
the tunnel disconnection procedure can be initiated by the UE or the ePDG. 

The tunnel is an IPsec tunnel (see IETF RFC 4301 [30]) established via an IKEv2 protocol exchange 

IETF RFC 5996 [28] between the UE and the ePDG. The UE may indicate support for IETF RFC 4555 [31]. The 

security mechanisms for tunnel setup using IPsec and IKEv2 are specified in 3GPP TS 33.402 [15]. 

7.2 UE procedures 
7.2.1 Selection of the ePDG 

For dynamic selection of the ePDG the UE shall support the implementation of standard DNS mechanisms in order to 
retrieve the IP address(es) of the ePDG. The input to the DNS query is an ePDG FQDN as specified in subclause 4.4.3 
and in 3GPP TS 23.003 [3]. The ePDG FQDN contains a PLMN ID as Operator Identifier. The UE selects the PLMN 
ID used in the ePDG FQDN based on the conditions described below. 

1. If the UE is EPS attached or GPRS attached (see 3GPP TS 23.122 [4]) to a Visited PLMN and: 

la) if the UE is not provided with a list of available PLMN ID(s), the UE shall use the PLMN identity of the 
RPLMN or an equivalent PLMN (see 3GPP TS 24.301 [10] or 3GPP TS 24.008 [46]) in the creation of the 
ePDG FQDN (see 3GPP TS 23.003 [3]);. If the DNS query with FQDN constructed using RPLMN identity 
does not return any IP address, then the UE as an implementation option may try again with FQDN 
constructed using an equivalent PLMN. 

lb) if the UE is provided with a list of available PLMN ID(s) served by the access network, e.g. through the 
access specific signalling as specified in 3GPP TS 24.234 [9], and the current RPLMN or an equivalent 
PLMN is contained in the list of available PLMN ID(s), the UE shall include this PLMN identity in the 
creation of the ePDG FQDN (see 3GPP TS 23.003 [3]); or 

Ic) in all other cases, the UE shall include the PLMN identity of the Home PLMN or EHPLMN in the ePDG 
FQDN. The HPLMN or EHPLMN shall be chosen based on the PLMN selection policy for the access 
network the UE is accessing e.g. see 3GPP TS 24.234 [9] subclause 5.2.4. 

2. If the UE is EPS attached or GPRS attached to the Home PLMN or EHPLMN and: 

2a) if the UE is not provided with a list of available PLMN ID(s), the UE shall use the PLMN identity of the 
Home PLMN or EHPLMN in the creation of the ePDG FQDN; or 

2b) if the UE is provided with a list of available PLMN ID(s) served by the access network e.g. through the 
access specific signalling as specified in 3GPP TS 24.234 [9], and the Home PLMN or EHPLMN is 
contained in the hst of available PLMN ID(s), then the UE shall use this PLMN identity in the ePDG FQDN; 

2c) in all other cases, the UE behaviour is implementation specific; or 

3. If the UE is not attached to any PLMN, the UE performs PLMN selection as described in subclause 5.2.1 and: 

3a) if the UE is provided with a list of available PLMN ID(s) served by the access network e.g. through the 
access specific signalling as specified in 3GPP TS 24.234 [9], and neither Home PLMN nor EHPLMN is 
contained in the list, use the PLMN identity of the selected PLMN from PLMN selection in the ePDG 
FQDN; or 

3b) otherwise, the UE shall include the identity of the Home PLMN or EHPLMN in the ePDG FQDN. 
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Upon reception of a DNS response containing one or more IP addresses of ePDGs, the UE shall select an IP address of 
ePDG with the same IP version as its local IP address. 

The UE shall select only one ePDG also in case of multiple PDN connections. 

NOTE: During handover between two untrusted non-3GPP access networks, the UE can initiate tunnel 
establishment to another ePDG while still being attached to the current ePDG. 

7.2.2 Tunnel establishment 

Once the ePDG has been selected, the UE shall initiate the IPsec tunnel establishment procedure using the IKEv2 
protocol as defined in IETF RFC 5996 [28] and 3GPP TS 33.402 [15]. 

The UE shall send an IKE_SA_INIT request message to the selected ePDG in order to setup an IKEv2 security 
association. Upon receipt of an IKE_S A_INIT response, the UE shall send an IKE_AUTH request message to the 
ePDG, including the type of IP address (IPv4 address or IPv6 prefix or both) that needs to be configured in an IKEv2 
CFG_REQUEST Configuration Payload. If the UE requests for both IPv4 address and IPv6 prefix, it shall send two 
configuration attributes in the CFG_REQUEST Configuration Payload, one for the IPv4 address and the other for the 
IPv6 prefix. The IKE_AUTH request message shall contain in "IDr" payload the APN and in the "IDi" payload the 
NAI. The UE indicates a request for the default APN by omitting IDr payload, which is in accordance with IKEv2 
protocol as defined in IETF RFC 5996 [28]. The IKE_AUTH request message may contain in a notify payload an 
indication that MOBIKE is supported by the UE. The UE may also include the INTERNAL_IP6_DNS or the 
INTERNAL_IP4_DNS attribute in the CFG_REQUEST Configuration Payload. The UE can obtain zero or more DNS 
server addressed in the CFG_REPLY payload as specified in IETF RFC 5996 [28]. 

During the IKEv2 authentication and security association establishment, if the UE supports explicit indication about the 
supported mobility protocols, it shall provide the indication as described in subclause 6.3. 

During the IKEv2 authentication and tunnel establishment for initial attach, the UE shall provide an indication about 
Attach Type, which indicates Initial Attach. To indicate attach due to initial attach, the UE shall include either the 
INTERNAL_IP4_ADDRESS or the INTERN AL_IP6_ADDRESS attribute or both in the CFG_REQUEST 
Configuration Payload within the IKE_AUTH request message. The INTERNAL_IP4_ADDRESS shall contain no 
value and the length field shall be set to 0. The INTERN AL_IP6_ADDRESS shall contain no value and the length field 
shall be set to 0. 

During the IKEv2 authentication and tunnel establishment for handover, the UE not supporting IP address preservation 
for NBM shall indicate Initial Attach as described in the previous paragraph. 

During the IKEv2 authentication and security association establishment for handover, the UE supporting IP address 
preservation for NBM, shall provide an indication about Attach Type, which indicates Handover Attach. To indicate 
attach due to handover, the UE shall include the previously allocated home address information during the IPSec tunnel 
establishment. Depending on the IP version, the UE shall include either the INTERN AL_IP4_ADDRESS or the 
INTERN AL_IP6_ADDRESS attribute or both in the CFG_REQUEST Configuration Payload within the IKE_AUTH 
request message to indicate the home address information which is in accordance with IKEv2 protocol as defined in 
IETF RFC 5996 [28]. The UE shall support IPSec ESP (see IETF RFC 4303 [32]) in order to provide secure tunnels 
between the UE and the ePDG as specified in 3GPP TS 33.402 [15]. 

The UE may support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [49] in 
order to support authentication and authorization with an external AAA server allowing the UE to support PAP 
authentication procedure, or CHAP authentication procedure, or both, as described in 3GPP TS 33.402 [15]. 

If NBM is used and the UE wishes to access an external PDN and therefore needs to perform authentication and 
authorization with an external AAA server, the UE shall: 

- If the IKE_S A_INIT response contains a " MULTIPLE. AUTH_SUPPORTED" Notify payload, then include a 
"MULTIPLE_AUTH_SUPPORTED" Notify payload in the IKE_AUTH request as described in 

IETF RFC 4739 [49] and perform the additional authentication steps as specified in 3GPP TS 33.402 [15]; and 

- If the IKE_S AJNIT response does not contain a "MULTIPLE_AUTH_SUPPORTED" Notify payload, then 
perform the UE initiated disconnection as defined in subclause 7.2.4.1. The subsequent UE action is 
implementation dependent (e.g. select a new ePDG). 

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify Payload 
with a Private Notify Message Type PDN_CONNECTION_REJECTION as specified in subclause 8.1.2 that includes 
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an IP address information in the Notification Data field, the UE shall not attempt to re-establish this PDN connection 
while connected to the current ePDG and the UE shall close the related IKEv2 security association states. 

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify Payload 
with a Private Notify Message Type PDN_CONNECTION_REJECTION as specified in subclause 8.1.2 and no 
Notification Data field, the UE shall not attempt to establish additional PDN connections to this APN while connected 
to the current ePDG. The UE shall close the related IKEv2 security association states. Subsequently, the UE can attempt 
to establishment additional PDN connections to the given APN if one or more existing PDN connections to the given 
APN are released. 

If NBM is used and if the UE receives from the ePDG an IKE_AUTH response message containing a Notify Payload 
with a Private Notify Message Type MAX_CONNECTION_REACHED as specified in subclause 8.1.2, the UE shall 
not attempt to establish any additional PDN connections while connected to the current ePDG. The UE shall close the 
related IKEv2 security association states. Subsequently, the UE can attempt to establishment additional PDN 
connections if one or more existing PDN connections are released. 

After the successful authentication with the 3GPP AAA server, the UE receives from the ePDG an IKE_AUTH 
response message containing a single CFG_REPLY Configuration Payload including the assigned remote IP address 
information (IPv4 address or IPv6 prefix) as described in subclause 7.4.1. Depending on the used IP mobility 
management mechanism the following cases can be differentiated: 

If DSMIPv6 is used for IP mobility management, the UE configures a remote IP address based on the IP 
address information contained in the INTERNAL_IP4_ADDRESS or INTERNAL_IP6_SUBNET attribute of 
the CFG_REPLY Configuration Payload. The UE uses the remote IP address as Care-of- Address to contact the 
HA. 

If NBM is used for IP mobility management and the UE performs an initial attach, the UE configures a home 
address based on the address information from the CFG_REPLY Configuration Payload. Otherwise, if NBM is 
used and the UE performs a handover attach, the UE continues to use its IP address configured before the 
handover, if the address information provided in the CFG_REPLY Configuration Payload does match with the 
UE's IP address configured before the handover. If the UE's IP address does not match with the address 
information of the CFG_REPLY Configuration Payload, the UE shall configure a new home address based on 
the IP address information contained in the INTERNAL_IP4_ADDRESS or INTERNAL_IP6_SUBNET 
attribute of the CFG_REPLY Configuration Payload. In the latter case, the IP address preservation is not 
possible. 

If the UE supports DSMIPv6, the UE may request the HA IP address(es), by including a corresponding 
CFG_REQUEST Configuration Payload containing a HOME_AGENT_ADDRESS attribute. The 
HOME_AGENT_ADDRESS attribute content is defined in subclause 8.2.4.1. The HA IP address(es) requested in this 
attribute are for the APN for which the IPsec tunnel with the ePDG is set-up. In the CFG_REQUEST, the UE sets 
respectively the IPv6 address field and the optional IPv4 address field of the HOME_AGENT_ADDRESS attribute to 
0::0 and to 0.0.0.0. If the UE can not obtain the IP addresses of the HA via IKEv2 signalling, it uses the home agent 
address discovery as specified in 3GPP TS 24.303 [11]. 

In case the UE wants to establish multiple PDN connections and if the UE uses DSMIPv6 for mobility management, the 
UE shall use DNS as defined in 3GPP TS 24.303 [1 1] to discover the HA IP address(es) for the additional PDN 
connections after IKEv2 security association was established to the ePDG. 

7.2.3 Tunnel modification 

This procedure is used if MOBIKE as defined in IETF RFC 4555 [31] is supported by the UE. 

When there is a change of local IP address for the UE, the UE shall update the IKE security association with the new 
address, and shall update the IPsec security association associated with this IKE security association with the new 
address. The UE shall then send an INFORMATIONAL request containing the UPDATE_SA_ ADDRESSES 
notification to the ePDG. 

If, further to this update, the UE receives an INFORMATIONAL request with a COOKIE2 notification present, the UE 
shall copy the notification to the COOKIE2 notification of an INFORMATIONAL response and send it to the ePDG. 
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7.2.4 Tunnel disconnection 

7.2.4.1 UE initiated disconnection 

The UE shall use the procedures defined in the IKEv2 protocol (see IETF RFC 5996 [28]) to disconnect an IPsec tunnel 
to the ePDG. The UE shall close the incoming security associations associated with the tunnel and instruct the ePDG to 
do the same by sending the INFORMATIONAL request message including a "DELETE" payload. The DELETE 
payload shall contain either: 

i) Protocol ID set to " 1 " and no subsequent Security Parameters Indexes (SPIs) in the payload. This indicates 
closing of IKE security association, and implies the deletion of all IPsec ESP security associations that were 
negotiated within the IKE security association; or 

ii) Protocol ID set to "3" for ESP. The Security Parameters Indexes included in the payload shall correspond to the 
particular incoming ESP security associations at the UE for the given tunnel in question. 

7.2.4.2 UE behaviour towards ePDG initiated disconnection 

On receipt of the INFORMATIONAL request message including "DELETE" payload, indicating that the ePDG is 
attempting tunnel disconnection, the UE shall: 

i) Close all security associations identified within the DELETE payload (these security associations correspond to 
outgoing security associations from the UE perspective). If no security associations were present in the DELETE 
payload, and the protocol ID was set to "1", the UE shall close the IKE security association, and all IPsec ESP 
security associations that were negotiated within it towards the ePDG; and 

ii) The UE shall delete the incoming security associations corresponding to the outgoing security associations 
identified in the "DELETE" payload. 

The UE shall send an INFORMATIONAL response message. If the INFORMATIONAL request message contained a 
list of security associations, the INFORMATIONAL response message shall contain a list of security associations 
deleted in step (ii) above. 

If the UE is unable to comply with the INFORMATIONAL request message, the UE shall send INFORMATION 
response message with either: 

i) A NOTIFY payload of type "INVALID_SPr', for the case that it could not identify one or more of the Security 
Parameters Indexes in the message from the ePDG; or 

ii) A more general NOTIFY payload type. This payload type is implementation dependent. 

7.3 3GPP AAA server procedures 

The UE - 3GPP AAA server procedures are as specified in 3GPP TS 29.273 [17] and 3GPP TS 33.402 [15]. 

7.4 ePDG procedures 
7.4.1 Tunnel establishment 

Upon receipt of an IKE_AUTH request message from the UE requesting the establishment of a tunnel, the ePDG shall 
proceed with authentication and authorization. The basic procedure described in 3GPP TS 33.402 [15], while further 
details are given below. 

During the UE's authentication and authorization procedure, the 3GPP AAA server provides to the ePDG an indication 
about the selected IP mobility mechanism as specified in 3GPP TS 29.273 [17]. 

The ePDG shall proceed with IPsec tunnel setup completion and shall relay in the IKEv2 Configuration Payload 
(CFG_REPLY) of the final IKE_AUTH response message the remote IP address information to the UE. If NBM is used 
as IP mobility mechanism, the ePDG shall assign either an IPv4 address or an IPv6 Home Network Prefix or both to the 
UE via a single CFG_REPLY Configuration Payload. If the UE requests for both IPv4 address and IPv6 prefix, but the 
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ePDG only assigns an IPv4 address or an IPv6 Home Network Prefix due to subscription restriction or network 
preference, the ePDG shall include the assigned remote IP address information (IPv4 address or IPv6 prefix) via a 
single CFG_REPLY Configuration Payload. If the ePDG assigns an IPv4 address, the CFG_REPLY contains the 
INTERN AL_IP4_ADDRESS attribute. If the ePDG assigns an IPv6 Home Network Prefix, the CFG_REPLY contains 
the INTERN AL_IP6_SUBNET configuration attribute. The ePDG obtains the IPv4 address and/or the IPv6 Home 
Network Prefix from the PDN GW. If the UE does not provide an APN to the ePDG during the tunnel establishment, 
the ePDG shall include the default APN in the IDr payload of the IKE_AUTH response message. If the UE included the 
INTERNAL_IP6_DNS or the INTERNAL_IP4_DNS in the CFG_REQUEST Configuration payload, the ePDG shall 
include the same attribute in the CFG_REPLY Configuration payload including zero or more DNS server addresses as 
specified in IETF RFC 5996 [28]. 

If DSMIPv6 is used as IP mobility mechanism, depending on the information provided by the UE in the 
CFG_REQUEST payload the ePDG shall assign to the UE either a local IPv4 address or local IPv6 address (or a local 
IPv6 prefix) via a single CFG_REPLY Configuration Payload. If the ePDG assigns a local IPv4 address, the 
CFG_REPLY contains the INTERN AL_IP4_ADDRESS attribute. If the ePDG assigns a local IPv6 address or a local 
IPv6 prefix the CFG_REPLY contains correspondingly the INTERN AL_IP6_ADDRESS or the 
INTERN AL_IP6_SUBNET attribute. If the UE provided an APN to the ePDG during the tunnel establishment, the 
ePDG shall not change the provided APN and shall include the APN in the IDr payload of the IKE_AUTH response 
message. An IPsec tunnel is now established between the UE and the ePDG. 

If NBM is used and if the ePDG needs to reject a PDN connection due to the network policies or the ePDG capabilities 
to indicate that no more PDN connection request of the given APN can be accepted for the UE, the ePDG shall include 
in the IKE_AUTH response message containing the IDr payload a Notify Payload with a Private Notify Message Type 
PDN_CONNECTION_REJECTION as specified in subclause 8.1.2. Additionally if the IKE_AUTH request message 
from the UE indicated Handover Attach as specified in subclause 7.2.2, the Notification Data field of the Notify 
Payload shall include the IP address information from the Handover Attach indication. If the UE indicated Initial 
Attach, the Notification Data field shall be omitted. If the ePDG needs to reject a PDN connection due to the network 
policies or capabilities to indicate that no more PDN connection request with any APN can be accepted for the UE, the 
ePDG shall include in the IKE_AUTH response message containing the IDr payload a Notify Payload with a Private 
Notify Message Type MAX_CONNECTION_REACHED as specified in subclause 8.1.2. 

If the UE indicates Handover Attach by including the previously allocated home address information and the ePDG 
obtains one or more PDN GW identities from the 3GPP AAA server, the ePDG shall use these identified PDN GWs in 
the subsequent PDN GW selection process. If the UE indicates Initial Attach i.e. home address information not 
included, the ePDG may run its initial PDN GW selection process to determine the PDN GW without using the received 
PDN GW identities. 

The ePDG shall support IPSec ESP (see IETF RFC 4303 [32]) in order to provide secure tunnels between the UE and 
the ePDG as specified in 3GPP TS 33.402 [15]. 

During the IKEv2 authentication and tunnel establishment, if the UE requested the HA IP address(es) and if DSMIPv6 
was chosen and if the HA IP address(es) are available, the ePDG shall provide the HA IP address(es) (IPv6 address and 
optionally IPv4 address) for the corresponding APN as specified by the "IDr" payload in the IKE_AUTH request 
message by including in the CFG_REPLY Configuration Payload a HOME_AGENT_ADDRESS attribute. In the 
CFG_REPLY, the ePDG sets respectively the IPv6 Home Agent address field and optionally the IPv4 Home Agent 
address field of the HOME_AGENT_ADDRESS attribute to the IPv6 address of the HA and to the IPv4 address of the 
HA. If no IPv4 HA address is available at the ePDG or if it was not requested by the UE, the ePDG shall omit the IPv4 
Home Agent Address field. If the ePDG is not able to provide an IPv6 HA address for the corresponding APN, then the 
ePDG shall not include a HOME_AGENT_ADDRESS attribute in the CFG_REPLY. 

The ePDG may support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [49] in 
order to support additional authentication and authorization of the UE with an external AAA server. 

If the ePDG supports authentication and authorization of the UE with an external AAA server, on receipt of an 
IKE_SA_INIT message the ePDG shall include a Notify payload of type "MULTIPLE_AUTH_SUPPORTED" in the 
IKE_SA_INIT response message to the UE. 

On successful completion of authentication and authorization procedure of the UE accessing EPC and on receipt of an 
IKE_AUTH request containing a Notify payload of type "ANOTHER_AUTH_FOLLOWS", the ePDG shall send an 
IKE_AUTH response containing the "AUTH" payload. 

Upon receipt of a subsequent IKE_AUTH request from the UE containing the user identity in the private network 
within the "IDi" payload, the ePDG shall: 
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if PAP authentication is required, then send an EAP-GTC request to the UE within an IKE_AUTH response 
message. Upon receipt of an EAP-GTC response from the UE, the ePDG shall use the procedures defined in 
3GPP TS 29.275 [18] and 3GPP TS 29.274 [50] to authenticate the user with the external AAA server; and 

if CHAP authentication is required, then send an EAP MD5 -Challenge request to UE. Upon receipt of EAP 
MD5-Challenge response within an IKE_AUTH request message from the UE, the ePDG shall use the 
procedures defined in 3GPP TS 29.275 [18] and 3GPP TS 29.274 [50] to authenticate the user with the external 
AAA server. If the ePDG receives Legacy-Nak response containing EAP-GTC type from the UE (see 
IETF RFC 3748 [29]) the ePDG may change the authentication and authorization procedure. If the ePDG does 
not change the authentication and authorization procedure or if the ePDG receives a Legacy-Nak response not 
containing EAP-GTC, the ePDG shall send an EAP-Failure to the UE. 

NOTE: The signalling flows for authentication and authorization with an external AAA server are described in 
3GPPTS 33.402 [15]. 

7.4.2 Tunnel modification 

When receiving an INFORMATIONAL request containing the UPDATE_SA_ ADDRESSES notification, the ePDG 
shall check the validity of the IP address and update the IP address in the IKE security association with the values from 
the IP header. The ePDG shall reply with an INFORMATIONAL response. 

The ePDG may initiate a return routability check for the new address provided by the UE, by including a COOKIE2 
notification in an INFORMATIONAL request and send it to the UE. When the ePDG receives the INFORMATIONAL 
response from the UE, it shall check that the COOKIE2 notification payload is the same as the one it sent to the UE. If 
it is different, the ePDG shall close the IKE security association by sending an INFORMATIONAL request message 
including a "DELETE" payload. 

If no return routability check is initiated by the ePDG, or if a return routability check is initiated and is successfully 
completed, the ePDG shall update the IPsec security associations associated with the IKE security association with the 
new address. 

7.4.3 Tunnel disconnection 

7.4.3.1 ePDG initiated disconnection 

The ePDG shall use the procedures defined in the IKEv2 protocol (see IETF RFC 5996 [28]) to disconnect an IPsec 
tunnel to the UE. The ePDG shall close the incoming security associations associated with the tunnel and instruct the 
UE to do likewise by sending the INFORMATIONAL request message including a "DELETE" payload. The DELETE 
payload shall contain either: 

i) Protocol ID set to " 1 " and no subsequent Security Parameter Indexes in the payload. This indicates that the IKE 
security association, and all IPsec ESP security associations that were negotiated within it between ePDG and 
UE shall be deleted; or 

ii) Protocol ID set to "3" for ESP. The SECURITY PARAMETERS INDEXES s included in the payload shall 
correspond to the particular incoming ESP SECURITY ASSOCIATION at the UE for the given tunnel in 
question. 

7.4.3.2 ePDG behaviour towards UE initiated disconnection 

On receipt of the INFORMATIONAL request message including "DELETE" payload indicating that the UE is 
initiating tunnel disconnect procedure, the ePDG shall: 

i) Close all security associations identified within the DELETE payload (these security associations correspond to 
outgoing security associations from the ePDG perspective). If no security associations were present in the 
DELETE payload, and the protocol ID was set to "1", the ePDG shall close the IKE security association, and all 
IPsec ESP security associations that were negotiated within it towards the UE; and 

ii) The ePDG shall delete the incoming security associations corresponding to the outgoing security associations 
identified in the "DELETE" payload. 
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The ePDG shall send an INFORMATIONAL response message. This shall contain a list of security associations deleted 
in step (ii) above. 

If the ePDG is unable to comply with the INFORMATIONAL request message, the ePDG shall send INFORMATION 
response message with either: 

i) a NOTIFY payload of type "INVALID_SPI", for the case that it could not identify one or more of the 
SECURITY PARAMETERS INDEXES in the message from the UE; or 

ii) a more general NOTIFY payload type. This payload type is implementation dependent. 



8 PDUs and parameters specific to the present 

document 

8.1 3GPP specific coding information defined within present 
document 

8.1 .1 Access Network Identity format and coding 

8.1 .1 .1 Generic format of the Access Network Identity 

The Access Network Identity shall take the generic format of an octet string without terminating null characters. The 
length indicator for the ANID is 2 bytes long, see IETF RFC 5448 [38]. Representation as a character string is allowed, 
but this character string shall be converted into an octet string of maximum length 253 according to UTF-8 encoding 
rules as specified in IETF RFC 3629 [34] before the Access Network Identity is input to the Key Derivation Function, 
as specified in 3GPP TS 33.402 [15], or used in the Access Network Identity indication from 3GPP AAA server to UE, 
cf subclause 8.2.2. The ANID is structured as an ANID Prefix and none, one or more ANID additional character strings 
separated by the colon character ":". In case additional ANID strings are not indicated the complete ANID consists of 
the ANID Prefix character string only. The ANID shall be represented by Unicode characters encoded as UTF-8 as 
specified in IETF RFC 3629 [34] and formatted using Normalization Form KC (NFKC) as specified in Unicode 5.L0, 
Unicode Standard Annex #15; Unicode Normalization Forms [41]. 

8.1 .1 .2 Definition of Access Network Identities for Specific Access Networks 

Table 8.1.1.2 specifies the list of Access Network Identities defined by 3GPP in the context of non-3GPP access to 
EPC. 
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Table 8.1.1.2: Access Network Identities 



Access Network Identity 


Type of Access Network 


ANID Prefix 


Additional ANID strings 




"HRPD" constant character 
string, see NOTE 1 and 
NOTE 2 


No additional ANID 
string, see NOTE 2 and 
NOTE 6 


cdma2000® HRPD access 
network 


"WIMAX" constant 
character string, see 
NOTE 1 


No additional ANID 
string, see NOTE 3 and 
NOTE 6 


WilVlAX access network 


"WLAN" constant character 
string, see NOTE 1 


No additional ANID 
string, see NOTE 4 and 
NOTE 6 


WLAN access network 


"ETHERNET" constant 
character string, see 
N0TE1 


No additional ANID 
string, see NOTE 5 and 
NOTE 6 


Fixed access network 


All other character strings 


Not applicable 


Not defined, see NOTE 6 and 
Annex B 


NOTE 1 : The quotes are not part of the definition of the character string. 

NOTE 2: The value of the ANID Prefix for cdma2000® HRPD access networks is defined 
in 3GPP2 X.S0057 [20]. 3GPP2 is responsible for specifying possible additional 
ANID strings applicable to the "HRPD" ANID Prefix. 

NOTE 3: WilVlAX Forum is responsible for specifying possible additional ANID strings 
applicable to the "WIIVlAX" ANID Prefix. 

NOTE 4: IEEE 802 is responsible for specifying possible additional ANID strings 
applicable to the "WLAN" ANID Prefix. 

NOTE 5: IEEE 802 is responsible for specifying possible additional ANID strings 
applicable to the "ETHERNET" ANID Prefix. 

NOTE 6: Additional ANID Prefixes and ANID strings can be added to this table following 
the procedure described in the informative Annex B. 



8.1 .2 IKEv2 Notify Message Type value 



8.1.2.1 



Generic 



The IKEv2 Notify Message Type is specified in IETF RFC 4306 [28]. The value of Notify Message Type between 8192 
and 16383 is reserved for private Error usage. Only the private IKEv2 Notify Message Type used for this specification 
is specified in this subclause. 



8.1.2.2 



Private Notify Message - Error Types 



The Private Notify Message, Error Types defined in table 8.1.2.2-1 are error notifications which indicates an error while 
negotiating an lKEv2 SA for the PDN connection to the APN requested by the UE. Refer to table 8.1.2.2-1 for more 
details on what each error type means. 



£75/ 



3GPP TS 24.302 version 11.4.0 Release 11 



44 



ETSI TS 124 302 V1 1.4.0 (2012-10) 



Table 8.1 .2.2-1 : Private Error Types 



Notify Message 


Value 


Descriptions 


PDN_CONNECTION_REJECTION 


8192 


With an IP address information in Notification Data 

field: 

The PDN connection corresponding to the IP 
address information has been rejected. 

Without Notification Data field: 

The PDN connection corresponding to the 
requested APN has been rejected. No 
additional PDN connections to the given APN 
can be established. 


MAX_CONNECTION_REACHED 


8193 


The PDN connection has been rejected. No 
additional PDN connections can be established for 
the UE due to the network policies or capabilities. 
The maximum number of PDN connections per 
UE allowed to be established simultaneously is 1 1 
due to a limitation in the network mobility 
procedures. 



8.2 IETF RFC coding information defined within present 
document 



8.2.1 



IPIVIS attributes 



8.2.1.1 



AT IPMS IND attribute 



7 


6 


5 4 3 2 


1 







Attribute Type = AT IPMS IND 


octet 1 


Length = 1 


octet 2 


Value 


octet 3 
octet 4 



Figure 8.2.1.1 : ATJPMSJND attribute 
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Table 8.2.1.1: AT IPMS I ND attribute 



Octet 1 


indicates the type of attribute as AT_IPMS_IND with a value of 1 37. 


Octet 2 


is the length of this 


attribute which shall be set to 1 as per IETF RFC 4187 [33] 


Octet 3 and 4 


is the value of this attribute. Octet 3 is reserved and shall be coded as zero. Octet 4 


shall be set as follows. 


All other values 


are reserved. 


7 6 


5 


4 


3 


2 


1 





Protocol Supported 






















DSIVIIPv6 only 






















NBIVIonly 





















l\/IIPv4 only 














1 








DSIVIIPv6 and NBM both supported 














1 







MIPv4 and NBM both supported 














1 







DSMIPv6 and NBM Supported;DSMIPv6 preferred 














1 






DSMIPv6 and NBM Supported; NBM preferred 






















MIPv4 and NBM supported; MIPv4 preferred 





















MIPv4 and NBM supported; NBM preferred 





















MIPv4 and DSMIPv6 supported; MIPv4 preferred 




















MIPv4 and DSMIPv6 supported; DSMIPv6 preferred 













1 








MIPv4, DSMIPv6 and NBM supported; MIPv4 preferred 













1 







MIPv4, DSMIPv6 and NBM supported; DSMIPv6 preferred 













1 


1 





MIPv4, DSMIPv6 and NBM supported; NBM preferred 



8.2.1.2 



AT IPMS RES attribute 



7 


6 


5 4 3 2 


1 







Attribute Type = AT IPMS RES 


octet 1 


Length = 1 


octet 2 


Value 


octet 3 
octet 4 



Figure 8.2.1.2: AT_IPIVIS_RES attribute. 



Table 8.2.1.2: AT IPIVIS RES attribute 



Octet 1 indicates the type of attribute as AT_IPMS_RES with a value of 138. 



Octet 2 is the length of this attribute which shall be set to 1 as per IETF RFC 4187 [33] 

Octet 3 and 4 is the value of this attribute. Octet 3 is reserved and shall be coded as zero. 
Octet 4 shall be set as follows. All other values are reserved. 

7 6 5 4 3 2 10 Protocol Selected 

1 DSMIPV6 

10 NBM 

11 MIPv4 
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8.2.2 Access Network Identity indication attribute 



8.2.2.1 



Access Network Identity in the AT_KDF_INPUT attribute 



The Access Network Identity is indicated in the Network Name Field of the AT_KDF_INPUT attribute as specified in 
IETF RFC 5448 [38]. The Network Name Field shall contain the Access Network Identity as specified in 
subclause 8.1.1 of this specification. 

NOTE: IETF in IETF RFC 5448 [38] refers to this specification for the value of the Network Name field. 

8.2.3 Trust relationship indication attribute 
8.2.3.1 AT TRUST IND attribute 



7 


6 


5 4 3 2 1 







Attribute Type = AT TRUST IND 


octet 1 


Lengtii = 1 


octet 2 


Value 


octet 3 
octet 4 



Figure 8.2.3.1-1 : AT_TRUST_IND attribute 



Table 8.2.3.1-1: AT TRUST IND attribute 



Octet 1 indicates tine type of attribute as AT_TRUST_IND witii a value of 1 39. 



Octet 2 is the lengtii of tills attribute whicii siiall be set to 1 as per IETF RFC 4187 [33] 

Octet 3 and 4 is tiie value of tine attribute. Octet 3 is reserved and shiall be coded as zero. Octet 4 
shall be set as follows. All other values are reserved. 

7 6 5 4 3 2 10 Indicated Trust Relationship 

1 Trusted 

10 UnTrusted 



8.2.4 IKEv2 Configuration Payloads attributes 



8.2.4.1 



HOME AGENT ADDRESS attribute 



The HOME_AGENT_ADDRESS attribute is shown in figure 8.2.4.1-1. The length of the HOME_AGENT_ADDRESS 
attribute is 16 or 20 bytes. The IPv4 Home Agent Address field is optional. The HA's IPv6 and IPv4 addresses are laid 
out respectively in IPv6 Home Agent Address and IPv4 Home Agent Address fields in big endian order (aka most 
significant byte first, or network byte order), see IETF RFC 5996 [28]. 
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7 


6 


5 4 3 2 


1 





R 


Attribute Type 


Attribute Type 


Length 


IPv6 Home Agent Address 


IPv4 Home Agent Address 



Bits 

Octets 

1 

2 

3,4 

5-20 

21-24 

Figure 8.2.4.1-1 : HOME_AGENT_ADDRESS attribute " 

The R bit in the first octet is defined in IETF RFC 5996 [28]. 

The Attribute Type indicating HOME_AGENT_ADDRESS is of the value 19. 

8.2.5 Full name for network and short name for network 
8.2.5.1 AT_FULL_NAME_FOR_NETWORK attribute 

The AT_FULL_NAME_FOR_NETWORK attribute is coded according to figure 8.2.5.1-1 and table 8.2.5.1-1. 



7 


6 5 


4 3 2 1 







Attribute Type = 


= AT FULL NAME FOR NETWORK 




Length 


Full name length 


Full name value 


Padding 



octet 1 


octet 2 


octet 3 


octet 4 


octet n 
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Figure 8.2.5.1-1 : AT_FULL_NAIVIE_FOR_NETWORK attribute 
Table 8.2.5.1-1: AT FULL NAME FOR NETWORK attribute 



Octet 1 indicates the type of this attribute as AT_FULL_NAIVIE_FOR_NETWORK with a value of 
xxxl. 

Editor note (WID: TEIl 1, CR#0195): the value of this skippable attribute needs to be allocated 
by lANA using registration procedure where "Specification Required" applies. 

Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 41 87 [33]. 

Octet 3 is the full name length field and contains the length of the full name value field in octets. 

The full name value field starts at octet 4 and its length is indicated by the full name length field. The 
full name value field indicates the "full length name of the network" that the network wishes the UE to 
associate with MCC and MNC in the realm of the NAI used during authentication. The structure of the 
full name value field is the same as the structure of the Network Name defined in 
3GPP TS 24.008 [46] subclause 1 0.5.3.5a except for the Network Name lEI and the Length of 
Network Name contents which are not included. 

The optional padding field starts after the last octet of the full name value field. Each octet of this field 
is set to zero by sending entity and discarded by receiving entity. 



8.2.5.2 AT_SHORT_NAME_FOR_NETWORK attribute 

The AT_SHORT_NAME_FOR_NETWORK attribute is coded according to figure 8.2.5.2-1 and table 8.2.5.2-1. 
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Figure 8.2.5.2-1 : AT_SHORT_NAME_FOR_NETWORK attribute 
Table 8.2.5.2-1 : AT SHORT NAME FOR NETWORK attribute 



Octet 1 indicates tlie type of ttiis attribute as AT_SHORT_NAIVIE_FOR_NETWORK witti a value of 
xxx2. 

Editor note (WID: TEIl 1, CR#0195): the value of this skippable attribute needs to be allocated 
by lANA using registration procedure where "Specification Required" applies. 

Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 41 87 [33]. 

Octet 3 is the short name length field and contains the length of the short name value field in octets. 

The short name value field starts at octet 4 and its length is indicated by the short name length field. 
The short name value field indicates the "abbreviated name of the networl<" that the network wishes 
the UE to associate with MCC and MNC in the realm of the NAI used during authentication. The 
structure of the short name value field is the same as the structure of the Networl< Name defined in 
3GPP TS 24.008 [46] subclause 1 0.5.3.5a except for the Networl< Name IE! and the Length of 
Network Name contents which are not included. 

The optional padding field starts after the last octet of the short name value field. Each octet of this 
field is set to zero by sending entity and discarded by receiving entity. 



8.2.6 Handling of the unknown protocol data 

If the receiving entity receives an unknown value in a recognized skippable attribute in an EAP-AKA or EAP-AKA' 
message, the receiving entity shall discard the attribute and shall handle the rest of the message. The definition of 
skippable attribute see the RFC 4187 [33]. The receiving entity handling of the unrecognized skippable attribute is as 
specified in RFC 4187 [33]. 
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Annex A (informative): 

Example signalling flows for inter-system change between 

3GPP and non-3GPP systems using ANDSF 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for mobility between 3GPP and non-3GPP systems. These signalling 
flows provide as example detailed information on Network Discovery and Selection aspects involving the use of 
ANDSF. 

A.2 Signalling flow for inter-system change between 
3GPP access network and non-3GPP access 
network 

Figure Al below shows an inter-system change procedure between 3GPP access network and non-3GPP access network 
using information obtained from ANDSF. 

In this example the UE uses DHCP query to obtain the IP address of the ANDSF. 

In this example flow, the communication between the UE and ANDSF does not imply use of any specific protocol. 

The steps involved in inter-system change between 3GPP access network and non-3GPP access network are as follows. 
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Figure A1. Procedure for Inter-system change between 3GPP access and non-3GPP using ANDSF 

1. Initial connectivity 

The UE is connected to 3GPP network. The current apphcations are supported over the 3GPP access network. 

NOTE: The procedure remains the same if the UE is initially connected to non-3GPP access network and wants 
to change to 3GPP access network. 
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2. Pre-provisioned policies 

The inter-system mobility policy is pre-provisioned on the UE. Based on pre-provisioned operator policies the 
UE has preference for different non-3GPP networks such as WLAN, and WiMAX. The UE can select these 
access networks when they are available. 

3. ANDSF Discovery 

ANDSF discovery is performed as described in subclause 6.8.2.2.1. The UE can discover ANDSF using DHCP 
query options as specified in IETF RFC 6153 [37], where ANDSF may be identified with a specific sub-option 
code. Optionally, the home operator can use OMA-DM's bootstrap mechanism as specified in OMA-ERELD- 
DM-V1_2 [39] to provide ANDSF information and security parameters for application layer authentication. 
Transport security is ensured by establishing an https tunnel between the UE and ANDSF, 

4. Policy Update based on Network Triggers 

Based on network triggers the ANDSF sends an updated inter-system mobility policy to the UE. The inter- 
system mobility policy includes validity conditions, i.e. conditions indicating when the policy is valid. Such 
conditions can include time duration, location area, etc. 

5. Evaluate which non-3GPP networks to discover 

The inter-system mobility policies specify the access networks that the UE can select; the UE has both WLAN 
and WiMAX radios. In this case, the inter-system mobility policy provided by the operator allows the UE to 
select either WLAN or WiMAX networks under all conditions. The UE, taking into account of the UE's local 
policy, e.g. user preference settings, access history, obtains information about availability of both WLAN and 
WiMAX access networks in its vicinity. 

6. Access Network Information Request 

The UE sends a request to ANDSF to get information about available access networks. The UE also includes its 
location information in the request. ANDSF can limit the information sent to UE based on internal settings. 

7. Access Network Information Response 

The ANDSF sends a response to the UE which includes the list of available access networks types (in order of 
operator preferences), access network identifier and PLMN identifier. In this case the ANDSF responds with 
availability of both WLAN and WiMAX network in the vicinity of the UE. 

8. Evaluate candidate non-3GPP networks 

Based on the received information and UE's local policy, the UE evaluates if it is within the coverage area of the 
available access networks in the order of preferences. In this case,based on the history and radio quality of 
WiMAX, the UE prefers WiMAX over WLAN access type. The UE powers on the WiMAX radio and checks 
for the presence of WiMAX network. The UE can listen to WiMAX broadcast messages (uplink/downlink 
channel data messages) and determines the presence of WiMAX network. Since the WiMAX network is the 
preferred network and since the UE has verified the presence of WiMAX network, the UE does not check for 
presence of WLAN network. 

9. Non-3GPP Network Selection 

The UE selects the most preferred available access network for inter-system mobility. In this case the UE selects 
the WiMAX access network. 

10. Inter-system change Procedure 

The UE initiates inter-system change procedure to the selected non-3GPP access network. The details of the 
inter-system change procedure are described elsewhere, see 3GPP TS 23.402 [6]. 
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Annex B (informative): 

Assignment of Access Network Identities in 3GPP 

This annex describes the recommended assignment procedure of Access Network Identities within 3GPP. 

B.1 Access Network Identities 

According to 3GPP TS 23.003 [3] the encoding of the Access Network Identity is specified within 3GPP, but the 
Access Network Identity definition for each non-3GPP access network is under the responsibility of the corresponding 
standardisation organisation respectively. 

If a standardisation organisation for a non-3GPP access network determines they need to define a new Access Network 
Identity Prefix or additional ANID strings, they can contact the 3GPP TSG-CT WG 1 via a Liaison Statement and 
indicate the specific values of the Access Network Identity Prefixes or the specific values of, or construction principles 
for, the additional ANID strings to be specified by 3GPP and give reference to the corresponding specification(s) of the 
requesting organisation. 3GPP TSG CT WG 1 will then specify the values for the Access Network Identities by 
updating Table 8.1.1.2 in this specification and inform the requesting standardisation organisation. 
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Annex C (informative): 
Example usage of ANDSF 

C.1 Scope of ANDSF Example 

This Annex gives an example of organization of ANDSF database and how it can be used to discover access network 
information. In this example the UE is in 3GPP network and is trying to discover available WiMAX networks. The 
ANDSF database is provided by the 3GPP operator with PLMN = PLMN_3GPP. 



C.2 Organization of ANDSF Coverage Map for WiMAX 
Network discovery 

Table CI illustrates the organization of ANDSF database for discovering WiMAX and WiFi networks. The ANDSF 
database provides the coverage mapping information for WiMAX and WiFi networks based on 3GPP cell identifiers. In 
this example the UE_Location can be specified either in terms of 3GPP parameters (PLMN + Cell Identifier) or in terms 
of geo spatial co-ordinates. 

Table CI : ANDSF Database Organization for PLMN = PLMN_3GPP 



UE Location 


AccessType = WiMAX 


AccessType = WiFi 


- 3GPP (Cellld) 






- Other (Geopriv) 






Locn 1 


NSP-ID=NSP 1: 


SSID=WiFi1, BSSID = BS1 


Celljd = Cell_1 


-NAP ID = NAP 1 
-NAP ID = NAP 2 
NSP-ID = NSP 2 
-NAP ID = NAP 2 
-NAP ID = NAP 3 


SSID=WiFi2, BSSID = BS2 


Locn 2 


NSP-ID = NSP 2 


N/A 


Cell Id = Cell 2 


- NAP ID = NAP 3 




Locn 3 


N/A 


SSID=WiFi1, BSSID = BS3 


Cell Id = Cell 3 




SSID=WiFi4, BSSID = BS4 








Locn n 


NSP-ID = NSP 1 


SSID=WiFi6, BSSID = BS5 


Cell Id = Cell n 


NAP ID = NAP 2 





For WiMAX network the database provides information about WiMAX NSP and NAP that provide coverage in 
respective 3GPP cells. Thus for example in 3GPP Cell_l, WiMAX Service provider NSP_1 provides service to 
WiMAX radio access providers NAP_1 and NAP-2. Similarly WiMAX Service Provider NSP_2 provides service to 
Network access providers NAP-2 and NAP_3 as well. Similarly in 3GPP Cell_2 WiMAX Network Service Provider 
NSP_2 provides service to network Access Provider NAP_3. Further it can be seen that no WiMAX coverage is 
available in 3GPP cell Cell 3. 



C.3 Parameters in Pull mode 

The UE is currently in 3GPP network. The UE sends a query to OMA ANDSF server as follows: 

ANDSF_Query ( UE_Location, AccessNetworkType= WiMAX ) 

The UE specifies the UE_Location information in terms of current 3GPP Cell Id (e.g. Cell_2) 

On receipt of the query message the ANDSF looks up the UE_Location (Cell_2) in the ANDSF database and searches 
for a prospective WiMAX entry. In this case the ANDSF retrieves WiMAX Service provider identifier (NSP-ID) 
NSP_2 and WiMAX Network Access Provider Identifier (NAP -ID) NAP_3. The ANDSF retrieves the network 
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parameters for this combination. The ANDSF fills these parameters in the WNDS MO and sends the information back 
to the UE. 

ANDSF_Response ( UE_Location, AccessNetworklnformationRef MO=WIMAXNDS). 
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Annex D (informative): 

Mismatch of static configuration of mobility mechanism in 

the UE and in the network 

This annex describes the possible cases of mismatch between the statically configured mobility mechanisms in the UE 
and in the EPC as shown in table D 1 . Additionally the table shows whether the UE would be able to access EPC 
services as a consequence of the mismatch. 
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Table D1 : Mismatch of static configuration of mobility mechanism in the UE and in the network 



NBM configured in the network 



DSMIPv6 configured in the 
network 



MIPv4 configured in the 
network 



NBIVI 

configured 

in the UE 



No mismatch 



Mismatch. The UE is not able to 
access EPC services because 
the UE configures a local IP 
address and there is no 
connectivity to the PGW in the 
EPC. Depending on operator"s 
policy and roaming agreements, 
local IP access services (e.g. 
Internet access) can be 
provided in the non-3GPP 
network using the local IP 
address. However, such local IP 
access services, where the user 
traffic does not traverse the 
EPC, are not described in this 
specification. 



IVIismatch. The UE is not 
able to access EPC services 
because the UE does not 
support communication with 
the Foreign Agent in the 
trusted non-3GPP network. 



DSMIPvG 

configured 

intheUE 



Mismatch. The UE can be able to 
access EPC services. After attach to 
the non-3GPP network, the UE is on 
the home link and configures an IP 
address based on the HNP, however 
in some cases the UE cannot detect 
the home link. Since the UE is 
configured with DSMIPv6, the UE 
would initiate a DSMIPv6 
bootstrapping: 

- If the network offers a HA function to 
the UE and if the bootstrapping is 
successful, the UE detects that it is 
attached to the home link. Depending 
of the UE capabilities and the network 
configuration, the UE can access 
EPC services via the S2a/S2b 
interface, but session continuity is not 
supported. 

- If the network does not offer a HA 
function or if the bootstrapping to the 
HA is not successful, the UE is not 
able to receive its Home Network 
Prefix and hence the UE cannot 
detect that it is on the home link. If no 
APN bound to the configured IP 
address was received and the access 
network doesn"t support APN 
delivery, the UE would not recognize 
the mismatch and cannot access 
EPC services. If the access network 
supports APN delivery and the 
configured IP address is bound to an 
APN, the UE can access EPC 
services. 



No mismatch 



Mismatch. The UE is not 
able to access EPC services 
because the UE does not 
support communication with 
the Foreign Agent in the 
trusted non-3GPP network. 



MIPv4 

configured 

intheUE 



Mismatch. The UE is not able to 
access EPC services because no 
Foreign Agent functionality is 
supported in the non-3GPP access 
network. 



Mismatch. The UE is not able to 
access EPC services because 
no Foreign Agent functionality is 
supported in the non-3GPP 
access network. 



No mismatch 
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Annex E (informative): 

UE procedures based on preconfigured and received 

information 

The flow diagrams in figure E-1 and figure E-2 show examples of the procedures that the UE can follow in order to 
establish a PDN connection based on information available to the UE about the authentication method, received or pre- 
configured access network trust relationship information or received or preconfigured IP mobility mode selection 
information. 

The following symbols are used: 

AN_TRUST trust relationship between the non-3GPP access network and the 3GPP EPC, considered to be 

applicable by the UE 
IPMM IP mobility mode, considered applicable by the UE 

Initially, at the entry to flow chart the UE has established contact with the non-3GPP access network, but the UE does 
not know whether it is in a trusted or untrusted access network. 
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Figure E-1. Procedures to be followed by the UE depending on received and preconfigured 

information - part 1 
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Figure E-2. Procedures to be followed by the UE depending on received and preconfigured 

information - part 2 
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